Alexander Lakhin <[email protected]> writes:
> Hello hackers,
> New buildfarm animal partridge (aarch64, maybe with slow storage)
> produced several unprecedented failures of 002_limits, e.g., [1], [2]:
I went looking at this tonight and then found your message. I think
the reason we're not seeing a lot of these in the buildfarm is that
not that many animals are running this test suite (it requires putting
xid_wraparound in PG_TEST_EXTRA). I concur with your conclusion that
poll_query_until is iterating the INSERT an extra time, but I think
a less magic solution would be to just change the test's match rule
to allow that to happen, more or less as attached.
regards, tom lane
diff --git a/src/test/modules/xid_wraparound/t/002_limits.pl b/src/test/modules/xid_wraparound/t/002_limits.pl
index 29d071a677b..ca2604d0c0d 100644
--- a/src/test/modules/xid_wraparound/t/002_limits.pl
+++ b/src/test/modules/xid_wraparound/t/002_limits.pl
@@ -126,14 +126,20 @@ $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 valid result, so it iterates an
+# additional time or times until the INSERT succeeds cleanly. So, we use
+# a "like" test that won't complain about extra data.
$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");
+after VACUUM/);
$node->stop;
done_testing();
