aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeFunctionscan.c
diff options
context:
space:
mode:
authorMichael Paquier <michael@paquier.xyz>2023-01-31 12:47:18 +0900
committerMichael Paquier <michael@paquier.xyz>2023-01-31 12:47:18 +0900
commite8fb2a721b361514d31d3dc7c5f1e3cae347106e (patch)
treed8c8ced18e50942cd38c2eefcec98f38fd943752 /src/backend/executor/nodeFunctionscan.c
parentb55303792afe9e4008815bfd87a51758f5736854 (diff)
downloadpostgresql-e8fb2a721b361514d31d3dc7c5f1e3cae347106e.tar.gz
postgresql-e8fb2a721b361514d31d3dc7c5f1e3cae347106e.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/executor/nodeFunctionscan.c')
0 files changed, 0 insertions, 0 deletions