xid_wraparound/002_limits.pl might fail due to transient warning

Hello hackers,

New buildfarm animal partridge (aarch64, maybe with slow storage)
produced several unprecedented failures of 002_limits, e.g., [1], [2]:
389/400 xid_wraparound - postgresql:xid_wraparound/002_limits ERROR           601.34s   exit status 1

[01:32:22.020](6.936s) not ok 3
[01:32:22.023](0.003s) #   Failed test at
/home/buildfarm/pg-buildfarm/builds/HEAD/pgsql/src/test/modules/xid_wraparound/t/002_limits.pl line 130.
[01:32:22.024](0.001s) #          got: 'start
# oldxact
# after 1 billion
# after 2 billion
# reached warn-limit
# after VACUUM
# after VACUUM'
#     expected: 'start
# oldxact
# after 1 billion
# after 2 billion
# reached warn-limit
# after VACUUM'

That is:
# Wait until autovacuum has processed the other databases and advanced
# the system-wide oldest-XID.
$ret =
  $node->poll_query_until('postgres',
    qq[INSERT INTO wraparoundtest VALUES ('after VACUUM')],
    'INSERT 0 1');

has been successfully executed two times instead of one.

002_limits_wraparound.log contains:
2026-07-24 01:32:21.791 UTC client backend[3424568] 002_limits.pl LOG:  statement: INSERT INTO wraparoundtest VALUES
('after VACUUM')
2026-07-24 01:32:21.793 UTC client backend[3424568] 002_limits.pl WARNING:  database "template0" must be vacuumed within
87544676 transactions
2026-07-24 01:32:21.793 UTC client backend[3424568] 002_limits.pl DETAIL:  Approximately 4.08% of transaction IDs are
available for use.
2026-07-24 01:32:21.793 UTC client backend[3424568] 002_limits.pl HINT:  To avoid transaction ID assignment failures,
execute a database-wide VACUUM in that database.
    You might also need to commit or roll back old prepared transactions, or drop stale replication slots.
2026-07-24 01:32:21.947 UTC client backend[3424573] 002_limits.pl LOG:  statement: INSERT INTO wraparoundtest VALUES
('after VACUUM')

First INSERT succeeded, but with the WARNING, which didn't satisfy
poll_query_until(). I've reproduced similar failures with extra
autovacuum/vacuum settings, but the reproducer is still too
timing-dependent to share, so maybe this illustration will do:
--- a/src/test/modules/xid_wraparound/t/002_limits.pl
+++ b/src/test/modules/xid_wraparound/t/002_limits.pl
@@ -95,6 +95,10 @@ is($warn_limit, 1, "warn-limit reached");
 # We can still INSERT, despite the warnings.
 $node->safe_psql('postgres',
     qq[INSERT INTO wraparoundtest VALUES ('reached warn-limit')]);
+$ret =
+  $node->poll_query_until('postgres',
+    qq[INSERT INTO wraparoundtest VALUES ('reached warn-limit')],
+    'INSERT 0 1');

PROVE_TESTS="t/002*" PG_TEST_EXTRA="xid_wraparound" PG_TEST_TIMEOUT_DEFAULT=5 make -s check -C
src/test/modules/xid_wraparound/
gives:
t/002_limits.pl .. 1/? # poll_query_until timed out executing this query:
# INSERT INTO wraparoundtest VALUES ('reached warn-limit')
# expecting this output:
# INSERT 0 1
# last actual query output:
# INSERT 0 1
# with stderr:
# WARNING:  database "postgres" must be vacuumed within 97483575 transactions
# DETAIL:  Approximately 4.54% of transaction IDs are available for use.
# HINT:  To avoid transaction ID assignment failures, execute a database-wide VACUUM in that database.
# You might also need to commit or roll back old prepared transactions, or drop stale replication slots.

Probably this can be fixed with (it works for my repro):
$ret =
  $node->poll_query_until('postgres',
    qq[SET client_min_messages='ERROR'; INSERT INTO wraparoundtest VALUES ('after VACUUM')],
    "SET\nINSERT 0 1");

[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=partridge&dt=2026-07-22%2011%3A37%3A59
[2] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=partridge&dt=2026-07-24%2000%3A00%3A42

Best regards,
Alexander