RE: Follow-up review items for update_deleted

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