summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorMichael Paquier2023-01-31 03:46:56 +0000
committerMichael Paquier2023-01-31 03:46:56 +0000
commit8c1cd726c5d997d5d170505ec15a2dc1dfe81d6a (patch)
tree80e6b05e6cdf9280b701cb0b7aa8eba99874e292
parent54e72b66ed1a55c2fa558bc60d534bdc61dbb62f (diff)
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/[email protected] Discussion: https://postgr.es/m/[email protected] Backpatch-through: 11
-rw-r--r--src/test/recovery/meson.build1
-rw-r--r--src/test/recovery/t/011_crash_recovery.pl63
2 files changed, 0 insertions, 64 deletions
diff --git a/src/test/recovery/meson.build b/src/test/recovery/meson.build
index edaaa1a3ce..209118a639 100644
--- a/src/test/recovery/meson.build
+++ b/src/test/recovery/meson.build
@@ -17,7 +17,6 @@ tests += {
't/008_fsm_truncation.pl',
't/009_twophase.pl',
't/010_logical_decoding_timelines.pl',
- 't/011_crash_recovery.pl',
't/012_subtransactions.pl',
't/013_crash_restart.pl',
't/014_unlogged_reinit.pl',
diff --git a/src/test/recovery/t/011_crash_recovery.pl b/src/test/recovery/t/011_crash_recovery.pl
deleted file mode 100644
index 5f945d2808..0000000000
--- a/src/test/recovery/t/011_crash_recovery.pl
+++ /dev/null
@@ -1,63 +0,0 @@
-
-# Copyright (c) 2021-2023, PostgreSQL Global Development Group
-
-#
-# Tests relating to PostgreSQL crash recovery and redo
-#
-use strict;
-use warnings;
-use PostgreSQL::Test::Cluster;
-use PostgreSQL::Test::Utils;
-use Test::More;
-
-my $node = PostgreSQL::Test::Cluster->new('primary');
-$node->init(allows_streaming => 1);
-$node->start;
-
-my ($stdin, $stdout, $stderr) = ('', '', '');
-
-# Ensure that pg_xact_status reports 'aborted' for xacts
-# that were in-progress during crash. To do that, we need
-# an xact to be in-progress when we crash and we need to know
-# its xid.
-my $tx = IPC::Run::start(
- [
- 'psql', '-X', '-qAt', '-v', 'ON_ERROR_STOP=1', '-f', '-', '-d',
- $node->connstr('postgres')
- ],
- '<',
- \$stdin,
- '>',
- \$stdout,
- '2>',
- \$stderr);
-$stdin .= q[
-BEGIN;
-CREATE TABLE mine(x integer);
-SELECT pg_current_xact_id();
-];
-$tx->pump until $stdout =~ /[[:digit:]]+[\r\n]$/;
-
-# Status should be in-progress
-my $xid = $stdout;
-chomp($xid);
-
-is($node->safe_psql('postgres', qq[SELECT pg_xact_status('$xid');]),
- 'in progress', 'own xid is in-progress');
-
-# Crash and restart the postmaster
-$node->stop('immediate');
-$node->start;
-
-# Make sure we really got a new xid
-cmp_ok($node->safe_psql('postgres', 'SELECT pg_current_xact_id()'),
- '>', $xid, 'new xid after restart is greater');
-
-# and make sure we show the in-progress xact as aborted
-is($node->safe_psql('postgres', qq[SELECT pg_xact_status('$xid');]),
- 'aborted', 'xid is aborted after crash');
-
-$stdin .= "\\q\n";
-$tx->finish; # wait for psql to quit gracefully
-
-done_testing();