Fix timing issue in deadlock recovery conflict test.
authorAndres Freund <andres@anarazel.de>
Wed, 4 May 2022 19:50:38 +0000 (12:50 -0700)
committerAndres Freund <andres@anarazel.de>
Wed, 4 May 2022 19:50:38 +0000 (12:50 -0700)
Per buildfarm members longfin and skink.

Discussion: https://postgr.es/m/20220413002626.udl7lll7f3o7nre7@alap3.anarazel.de
Backpatch: 10-

src/test/recovery/t/031_recovery_conflict.pl

index 192d2d5a31d5012cfef68ad8bdfcd19ec54a9d57..8dcb3da0de9e4c2b45317e76723b53287b68cfaf 100644 (file)
@@ -226,6 +226,14 @@ check_conflict_stat("tablespace");
 $sect = "startup deadlock";
 $expected_conflicts++;
 
+# Want to test recovery deadlock conflicts, not buffer pin conflicts. Without
+# changing max_standby_streaming_delay it'd be timing dependent what we hit
+# first
+$node_standby->adjust_conf('postgresql.conf', 'max_standby_streaming_delay',
+                                                  "${PostgreSQL::Test::Utils::timeout_default}s");
+$node_standby->restart();
+reconnect_and_clear();
+
 # Generate a few dead rows, to later be cleaned up by vacuum. Then acquire a
 # lock on another relation in a prepared xact, so it's held continuously by
 # the startup process. The standby psql will block acquiring that lock while
@@ -281,6 +289,9 @@ check_conflict_stat("deadlock");
 
 # clean up for next tests
 $node_primary->safe_psql($test_db, qq[ROLLBACK PREPARED 'lock';]);
+$node_standby->adjust_conf('postgresql.conf', 'max_standby_streaming_delay', '50ms');
+$node_standby->restart();
+reconnect_and_clear();
 
 
 # Check that expected number of conflicts show in pg_stat_database. Needs to