Hi Nick, On 7 Sep 2026, Nick Ivanov wrote: > reserve the WAL earlier in the process
This addresses the primary-side window. I should clarify my earlier suggestion for standbys, though: reserving the replay LSN and later lowering it is insufficient without an interlock with WAL removal. A restartpoint can remove the older start segment between selecting it and registering it. Updating the entry in place would avoid the unregister/register gap, but would not by itself close that earlier window. The reservation also needs cleanup from the moment it is registered. For example, the "backup label too long" error in do_pg_backup_start() occurs before its cleanup block and leaves the new array entry behind. For -X fetch, retention ends too early: do_pg_backup_stop() unregisters the startpoint before perform_base_backup() copies the WAL. I paused at an injection point just before the opt->includewal block, generated WAL, and ran CHECKPOINT. The start segment disappeared and v2 failed with the missing-WAL error. Retention and its error cleanup need to cover the WAL copy too. KeepLogSeg() also applies max_slot_wal_keep_size to the backup reservation. That allows a checkpoint to discard required WAL even while the reservation exists. Should that limit apply to backups at all? Unlike slots, these reservations have no invalidation mechanism. > and the introduction of a new GUC should therefore be acceptable. Even for HEAD, max_wal_senders already bounds concurrent BASE_BACKUP commands, including -X fetch: they all run in walsender processes. Could we size the array from that instead? I think the client-side fix is worth backpatching, even if this broader work stays on HEAD. One build note: my build warned about the missing declaration of BackupCtlShmemCallbacks. xlogbackup.c needs storage/subsystems.h for it. Thank you! Best regards, Andrey Borodin.
