On Monday, July 27th, 2026 at 9:57 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> I think we should at least have CFI in this loop so that it responds
> to promotion, shutdown, etc.
If the goal is to make the standby responsive to shutdown, we should
add ProcessStartupProcInterrupts(), which is already called elsewhere
during redo: xlog_redo() -> CheckRequiredParameterValues() ->
RecoveryRequiresIntParameter() -> ProcessStartupProcInterrupts()
in a loop. CHECK_FOR_INTERRUPTS() doesn't handle shutdown.
If the target is promotion, then we could use CheckForStandbyTrigger().
Conflict resolution occurs while the standby is processing a record,
and from what I can tell, responding to promotion after beginning to
apply the record but before finishing is unprecedented and would force
the standby to decide what to do with the partially-applied record.
The attached v2 calls ProcessStartupProcInterrupts(), and I confirmed
that the standby shuts down promptly when signaled.
On Mon, Jul 27, 2026 at 5:19 AM Michael Paquier
<michael@paquier.xyz> wrote:
>
> Adding a code pattern that could potentially cause this code path to
> loop infinitely is not what I would call a principled approach, I
> would call it a risky one.
I tried to cause an infinite loop using a standby with
max_standby_streaming_delay = 5s, max_connections = 400, and a pool of
clients that relays one old snapshot forward as fast as it can:
t= 1.1s 212 conflicting VXIDs
t= 5.5s 363 population stops growing, no connection slots left
t= 6.6s 277 cutoff has passed, cancellation begins
t= 7.7s 190
t= 8.8s 105
t= 9.9s 16
t=11.0s 0 replay resumes
The standby begins killing VXIDs and kills them too fast for a
sustained relay - at least on my machine with this setup. The standby
calls pg_usleep(5000) after each signal, which is why the
population remains above 0 for several seconds after the cutoff.
--
Scott Ray
