Stabilize xid_wraparound/t/002_limits.pl test.

Not many buildfarm members run this test, since it's gated behind
PG_TEST_EXTRA=xid_wraparound, but of those that do, the slower ones
not infrequently fail.  The reason seems to be that the test expects
an INSERT command to either succeed or fail, but there's a window
where it can succeed while issuing a warning about impending
wraparound.  poll_query_until treats nonempty stderr as a failure,
so it loops an extra time until the INSERT succeeds with no warning.
There seems no reason to treat this behavior as wrong, so adjust
the test to accept it.

Reported-by: Alexander Lakhin <exclusion@gmail.com>
Diagnosed-by: Alexander Lakhin <exclusion@gmail.com>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/7a68bee2-91bd-481d-be44-160e6beebc83@gmail.com
Backpatch-through: 17

src/test/modules/xid_wraparound/t/002_limits.pl

@@ -125,14 +125,19 @@ $ret =
 	qq[INSERT INTO wraparoundtest VALUES ('after VACUUM')],
 	'INSERT 0 1');
 
-# Check the table contents
+# Check the table contents.  It's possible for more than one "after VACUUM"
+# entry to appear, because there is a window where the preceding INSERT will
+# succeed but also produce a warning message about impending wraparound.
+# poll_query_until won't accept that as a successful result, so it iterates
+# an additional time or times until the INSERT succeeds cleanly.
 $ret = $node->safe_psql('postgres', qq[SELECT * from wraparoundtest]);
-is( $ret, "start
+like(
+	$ret, qr/^start
 oldxact
 after 1 billion
 after 2 billion
-reached warn-limit
-after VACUUM");
+reached warn-limit(
+after VACUUM)+$/);
 
 $node->stop;
 done_testing();