Dear Amit, Thanks for pushing a patch. I found two BF failures due to the commit [1], [2].
In added test we tried to assign a transaction ID then ensure xmin of the slot can be smaller. However, since query_until() could return before starting a new transaction, there was a case that $next_xid cannot be computed correctly. IIUC query_safe() returns after running all the command and it should be used here. Also, I found another unnecessary usage of query_until(), it's also fixed. Please see attached to fix the issue. This must be backpatched to PG19 and attached could be applied. [1]: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bushmaster&dt=2026-09-07%2019%3A48%3A18 [2]: https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=canebrake&dt=2026-09-07%2023%3A33%3A41 [3]: ``` # Hold a transaction with an assigned transaction ID open in dbb, pinning its # oldest active transaction ID. my $dbb_session = $node_B->background_psql('dbb'); $dbb_session->query_until( qr/starting_bg_psql/, q{ \echo starting_bg_psql BEGIN; SELECT txid_current(); }); # Push the transaction ID counter clearly past the pinned transaction ID and # wait for the slot's xmin to advance past it. Only the apply worker in the # postgres database drives the slot's xmin here, and postgres has no old # transaction running. $next_xid = $node_B->safe_psql('postgres', "SELECT txid_current() + 1"); ... # The slot's xmin must regress to the horizon pinned in dbb. ok( $node_B->poll_query_until( 'postgres', "SELECT xmin::text::bigint < $next_xid FROM pg_replication_slots WHERE slot_name = 'pg_conflict_detection'" ), "slot xmin regressed to the horizon pinned in dbb"); ``` Best regards, Hayato Kuroda FUJITSU LIMITED
0001-Stabilize-035_conflicts.pl.patch
Description: 0001-Stabilize-035_conflicts.pl.patch
