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

On Tue, Jan 27, 2026 at 10:11 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Tue, Jan 27, 2026 at 12:56 AM Amit Kapila <akapila(at)postgresql(dot)org> wrote:
> >> Prevent invalidation of newly synced replication slots.
>
> > This commit has broken CI for me.
>
> Hmm, I wonder why the buildfarm seems fine with it ... I'm prepared
> to believe a Windows-only problem, but at least hamerkop has run
> since 851f664.

I don't understand it, either. There's a bunch of error codes that we
map to EACCES in _dosmaperr, but I don't know why any of those
problems would have occurred here:

ERROR_ACCESS_DENIED, EACCES
ERROR_CURRENT_DIRECTORY, EACCES
ERROR_LOCK_VIOLATION, EACCES
ERROR_SHARING_VIOLATION, EACCES
ERROR_NETWORK_ACCESS_DENIED, EACCES
ERROR_CANNOT_MAKE, EACCES
ERROR_FAIL_I24, EACCES
ERROR_DRIVE_LOCKED, EACCES
ERROR_SEEK_ON_DEVICE, EACCES
ERROR_NOT_LOCKED, EACCES
ERROR_LOCK_FAILED, EACCES

(Side note: Wouldn't it make a lot of sense to go back and kill
_dosmaperr in favor of display the actual Windows error code string?)

What's also puzzling is that what this test is doing seems to be
totally standard. 040_standby_failover_slots_sync.pl does this:

my $standby1 = PostgreSQL::Test::Cluster->new('standby1');
$standby1->init_from_backup(
$primary, $backup_name,
has_streaming => 1,
has_restoring => 1);

And 046_checkpont_logical_slot.pl does this:

my $standby = PostgreSQL::Test::Cluster->new('standby');
$standby->init_from_backup(
$primary, $backup_name,
has_streaming => 1,
has_restoring => 1);

So why is 046 failing and 040 is fine? I have no idea.

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