Fix intermittent BF failures in 035_conflicts.
authorAmit Kapila <akapila@postgresql.org>
Tue, 16 Sep 2025 06:16:23 +0000 (06:16 +0000)
committerAmit Kapila <akapila@postgresql.org>
Tue, 16 Sep 2025 06:25:55 +0000 (06:25 +0000)
commit0f42206531b3646f5bcda2bd35bb53fb0488eb00
tree1211797b928e148c26a86277e464bf9c8b020ce8
parentbce18ef3c67be63ad2dd8d585260dcb813f5a525
Fix intermittent BF failures in 035_conflicts.

This commit addresses two sources of instability in the 035_conflicts
test:

Unstable VACUUM usage:
The test previously relied on VACUUM to remove a deleted column, which can
be unreliable due to concurrent background writer or checkpoint activity
that may lock the page containing the deleted tuple. Since the test
already verifies that replication_slot.xmin has advanced sufficiently to
confirm the feature's correctness, so, the VACUUM step is removed to
improve test stability.

Timing-sensitive retention resumption check:
The test includes a check to confirm that retention of conflict-relevant
information resumes after setting max_retention_duration to 0. However, in
some cases, the apply worker resumes retention immediately after the
inactive slot is removed from synchronized_standby_slots, even before
max_retention_duration is updated. This can happen if remote changes are
applied in under 1ms, causing the test to timeout while waiting for a
later log position. To ensure consistent behavior, this commit delays the
removal of synchronized_standby_slots until after max_retention_duration
is set to 0.

Author: Zhijie Hou <houzj.fnst@fujitsu.com>
Reviewed-by: shveta malik <shveta.malik@gmail.com>
Reviewed-by: Amit Kapila <amit.kapila16@gmail.com>
Discussion: https://postgr.es/m/TY4PR01MB16907805DE4816E53C54708159414A@TY4PR01MB16907.jpnprd01.prod.outlook.com
src/test/subscription/t/035_conflicts.pl