Re: pgsql: Prevent invalidation of newly synced replication slots.

On Wed, Jan 28, 2026 at 10:24 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
>
> I think it'd be worth, separately from committing the workaround, trying to
> figure out what's holding the file open. Andrey observed that the tests pass
> for him with a much longer timeout. If you can reproduce it locally, I'd try
> to use something like [2] to see what has handles open to the relevant files,
> while waiting for the timeout.
>

Thanks for the suggestion. I did some experiments by using handle.exe
and below are the results. To get the results, I added a long sleep
before rename of backup_label file.

After Fix:
==========
handle.exe D:\Workspace\Postgresql\head\postgresql\build\testrun\recovery\046_checkpoint_logical_slot\data\t_046_checkpoint_logical_slot_standby_data\pgdata\backup_label

Nthandle v5.0 - Handle viewer
Copyright (C) 1997-2022 Mark Russinovich
Sysinternals - www.sysinternals.com

No matching handles found.

Before Fix:
==========
handle.exe D:\Workspace\Postgresql\head\postgresql\build\testrun\recovery\046_checkpoint_logical_slot\data\t_046_checkpoint_logical_slot_standby_data\pgdata\backup_label

Nthandle v5.0 - Handle viewer
Copyright (C) 1997-2022 Mark Russinovich
Sysinternals - www.sysinternals.com

perl.exe pid: 33784 type: File 30C:
D:\Workspace\Postgresql\head\postgresql\build\testrun\recovery\046_checkpoint_logical_slot\data\t_046_checkpoint_logical_slot_standby_data\pgdata\backup_label
pg_ctl.exe pid: 51236 type: File 30C:
D:\Workspace\Postgresql\head\postgresql\build\testrun\recovery\046_checkpoint_logical_slot\data\t_046_checkpoint_logical_slot_standby_data\pgdata\backup_label
cmd.exe pid: 35332 type: File 30C:
D:\Workspace\Postgresql\head\postgresql\build\testrun\recovery\046_checkpoint_logical_slot\data\t_046_checkpoint_logical_slot_standby_data\pgdata\backup_label
postgres.exe pid: 48200 type: File 30C:
D:\Workspace\Postgresql\head\postgresql\build\testrun\recovery\046_checkpoint_logical_slot\data\t_046_checkpoint_logical_slot_standby_data\pgdata\backup_label
postgres.exe pid: 7420 type: File 30C:
D:\Workspace\Postgresql\head\postgresql\build\testrun\recovery\046_checkpoint_logical_slot\data\t_046_checkpoint_logical_slot_standby_data\pgdata\backup_label
postgres.exe pid: 17160 type: File 30C:
D:\Workspace\Postgresql\head\postgresql\build\testrun\recovery\046_checkpoint_logical_slot\data\t_046_checkpoint_logical_slot_standby_data\pgdata\backup_label
postgres.exe pid: 56192 type: File 30C:
D:\Workspace\Postgresql\head\postgresql\build\testrun\recovery\046_checkpoint_logical_slot\data\t_046_checkpoint_logical_slot_standby_data\pgdata\backup_label
postgres.exe pid: 53892 type: File 30C:
D:\Workspace\Postgresql\head\postgresql\build\testrun\recovery\046_checkpoint_logical_slot\data\t_046_checkpoint_logical_slot_standby_data\pgdata\backup_label
postgres.exe pid: 44732 type: File 30C:
D:\Workspace\Postgresql\head\postgresql\build\testrun\recovery\046_checkpoint_logical_slot\data\t_046_checkpoint_logical_slot_standby_data\pgdata\backup_label
postgres.exe pid: 43488 type: File 30C:
D:\Workspace\Postgresql\head\postgresql\build\testrun\recovery\046_checkpoint_logical_slot\data\t_046_checkpoint_logical_slot_standby_data\pgdata\backup_label

All the shown postgres processes are various standby processes. Below
are details of each postgres process:

43488: startup process
XLogCtl->SharedRecoveryState RECOVERY_STATE_ARCHIVE (1)

44732: bgwriter:
XLogCtl->SharedRecoveryState RECOVERY_STATE_ARCHIVE (1)

53892: checkpointer
XLogCtl->SharedRecoveryState RECOVERY_STATE_ARCHIVE (1)

56192: aio-worker
XLogCtl->SharedRecoveryState RECOVERY_STATE_ARCHIVE (1)

17160: aio-worker
XLogCtl->SharedRecoveryState RECOVERY_STATE_ARCHIVE (1)

7420: aio-worker
XLogCtl->SharedRecoveryState RECOVERY_STATE_ARCHIVE (1)

48200: postmaster
XLogCtl->SharedRecoveryState RECOVERY_STATE_ARCHIVE (1)

I printed XLogCtl->SharedRecoveryState to show all are standby processes.

The results are a bit strange in the sense that some unfinished psql
sessions of primary could lead standby processes to be shown in
results of handle.exe.

Note: I have access to this environment till tomorrow noon, so I can
try to investigate a bit tomorrow if there are more questions related
to the above experiment.

--
With Regards,
Amit Kapila.