diff options
author | Michael Paquier <michael@paquier.xyz> | 2023-01-31 12:46:56 +0900 |
---|---|---|
committer | Michael Paquier <michael@paquier.xyz> | 2023-01-31 12:46:56 +0900 |
commit | 8c1cd726c5d997d5d170505ec15a2dc1dfe81d6a (patch) | |
tree | 80e6b05e6cdf9280b701cb0b7aa8eba99874e292 /src/backend/commands/async.c | |
parent | 54e72b66ed1a55c2fa558bc60d534bdc61dbb62f (diff) | |
download | postgresql-8c1cd726c5d997d5d170505ec15a2dc1dfe81d6a.tar.gz postgresql-8c1cd726c5d997d5d170505ec15a2dc1dfe81d6a.zip |
Remove recovery test 011_crash_recovery.pl
This test has been added as of 857ee8e that has introduced the SQL
function txid_status(), with the purpose of checking that a transaction
ID still in-progress during a crash is correctly marked as aborted after
recovery finishes.
This test is unstable, and some configuration scenarios may that easier
to reproduce (wal_level=minimal, wal_compression=on) because the WAL
holding the information about the in-progress transaction ID may not
have made it to disk yet, hence a post-crash recovery may cause the same
XID to be reused, triggering a test failure.
We have discussed a few approaches, like making this function force a
WAL flush to make it reliable across crashes, but we don't want to pay a
performance penalty in some scenarios, as well. The test could have
been tweaked to enforce a checkpoint but that actually breaks the
promise of the test to rely on a stable result of txid_status() after
a crash.
This issue has been reported a few times across the past years, with an
original report from Kyotaro Horiguchi. The buildfarm machines tanager,
hachi and gokiburi enable wal_compression, and fail on this test
periodically.
Discussion: https://postgr.es/m/3163112.1674762209@sss.pgh.pa.us
Discussion: https://postgr.es/m/20210305.115011.558061052471425531.horikyota.ntt@gmail.com
Backpatch-through: 11
Diffstat (limited to 'src/backend/commands/async.c')
0 files changed, 0 insertions, 0 deletions