Re: 011_crash_recovery.pl intermittently fails
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Craig Ringer <craig.ringer@enterprisedb.com>,
Robert Haas <robertmhaas@gmail.com>
Date: 2021-03-05T04:40:34Z
Lists: pgsql-hackers
Thomas Munro <thomas.munro@gmail.com> writes: > On Fri, Mar 5, 2021 at 5:10 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Alternatively, maybe we can salvage the function's usefulness by making it >> flush WAL before returning? > To make pg_xact_status()'s result reliable, don't you need to make > pg_current_xact_id() flush? In other words, isn't it at the point > that you *observe* the transaction that you have to make sure that > this transaction ID won't be reused after crash recovery. Before > that, it's simultaneously allocated and unallocated, like the cat. We need to be sure that the XID is written out to WAL before we let the client see it, yeah. I've not looked to see exactly where in the code would be the best place. BTW, I tried simply removing the "allows_streaming" option from the test, and it failed ten times out of ten tries for me. So Andres is right that that makes it pretty reproducible in a stock build. regards, tom lane
Commits
-
Remove recovery test 011_crash_recovery.pl
- 403d82dd54b5 11.19 landed
- e8fb2a721b36 12.14 landed
- ee11824ac4c2 13.10 landed
- 96d42bd27fef 14.7 landed
- c5b2975ec183 15.2 landed
- 8c1cd726c5d9 16.0 landed
-
Add a txid_status function.
- 857ee8e391ff 10.0 cited