Re: pgsql: Prevent invalidation of newly synced replication slots. - Mailing list pgsql-hackers

From Robert Haas
Subject Re: pgsql: Prevent invalidation of newly synced replication slots.
Date
Msg-id CA+Tgmoa-RYWEkZi6tpp9TLrD+1kKFgxR6kgXCCiomMyDnh+ENw@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Prevent invalidation of newly synced replication slots.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pgsql: Prevent invalidation of newly synced replication slots.
List pgsql-hackers
On Tue, Jan 27, 2026 at 12:42 PM Robert Haas <robertmhaas@gmail.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



pgsql-hackers by date:

Previous
From: "Jelte Fennema-Nio"
Date:
Subject: Re: Safer hash table initialization macro
Next
From: Sami Imseih
Date:
Subject: Re: Optional skipping of unchanged relations during ANALYZE?