On Wed, Jan 28, 2026 at 10:24 PM Andres Freund <[email protected]> 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.
