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

On Tue, Jan 27, 2026 at 12:42 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 2026-01-27 17:19:25.354 GMT startup[2488] DEBUG: didn't need to
> unlink permanent stats file "pg_stat/pgstat.stat" - didn't exist
> 2026-01-27 17:19:38.938 GMT startup[2488] FATAL: could not rename
> file "backup_label" to "backup_label.old": Permission denied

Andrey Borodin pointed out to me off-list that there's a retry loop in
pgrename(). The 13 second delay between the above two log messages
almost certainly means that retry loop is iterating until it hits its
10 second timeout. This almost certainly means that the underlying
Windows error is ERROR_ACCESS_DENIED, ERROR_SHARING_VIOLATION, or
ERROR_LOCK_VIOLATION, and that somebody else has the file open. But
nothing other than Perl touches that directory before we try to start
the standby:

my $standby = PostgreSQL::Test::Cluster->new('standby');
$standby->init_from_backup(
$primary, $backup_name,
has_streaming => 1,
has_restoring => 1);
$standby->append_conf(
'postgresql.conf', qq(
hot_standby_feedback = on
primary_slot_name = 'phys_slot'
primary_conninfo = '$connstr_1 dbname=postgres'
log_min_messages = 'debug2'
));
$standby->start;

As far as I can see, only init_from_backup() touches the backup_label
file, and that just copies the directory using RecursiveCopy.pm, which
as far as I can tell is quite careful about closing file handles. So I
still have no idea what's happening here.

--
Robert Haas
EDB: http://www.enterprisedb.com