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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Amit Kapila <akapila(at)postgresql(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgsql: Prevent invalidation of newly synced replication slots.
Date: 2026-01-27 16:17:31
Message-ID: o5t5teaoz3ohto3xeftdumixoqyuee4u54ysyk4lvhpp54bd2w@h6citz4to4ib
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Hi,

On 2026-01-27 10:51:58 -0500, Robert Haas wrote:
> 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?)

It'd be great to somehow preserve the mapping to preserve the original error
message, but I don't really see how we could just give up on our mapping. We
rely on e.g. knowing that a read failed due to ENOENT, not
ERROR_FILE_NOT_FOUND or whatnot.

> 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.

046 does a fair bit of stuff before the base backup is being taken, I guess?
But what that concretely could be, I have no idea.

It'd be one thing if it failed while creating a base backup, but the fact that
it allows the base backup being created, but then fails during startup is just
plain odd. The typical sharing violation issue seems like it'd require that
we somehow are not waiting for pg_basebackup to actually have terminated?

Greetings,

Andres Freund

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Robert Haas 2026-01-27 16:17:43 Re: pgsql: Prevent invalidation of newly synced replication slots.
Previous Message Jeff Davis 2026-01-27 16:16:26 pgsql: Fix crash introduced by incorrect backport 806555e300.

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2026-01-27 16:17:43 Re: pgsql: Prevent invalidation of newly synced replication slots.
Previous Message Thomas Munro 2026-01-27 16:16:13 Re: pgsql: Prevent invalidation of newly synced replication slots.