On 2026-01-28 05:16:13 +1300, Thomas Munro wrote:

But I wonder if you can't rename("old", "new") where "new" is a file that
has already been unlinked (or renamed over) that someone still holds open,
or something like that...

I don't see a source of that that would be specific to this test though :(. We
do wait for pg_basebackup to have shut down, which wrote backup.label (which
was "manifactured" during streaming by basebackup.c).

But I wonder if you can't rename("old", "new") where "new" is a file that
has already been unlinked (or renamed over) that someone still holds open,
or something like that...

I don't see a source of that that would be specific to this test though :(. We
do wait for pg_basebackup to have shut down, which wrote backup.label (which
was "manifactured" during streaming by basebackup.c).

Perhaps we should crank up log level in the test? No idea if it'll help, but
right now I don't even know where to start looking.

What's also puzzling is that what this test is doing seems to be
totally standard.

		regards, tom lane

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:

ERRORACCESSDENIED, EACCES
ERRORCURRENTDIRECTORY, EACCES
ERRORLOCKVIOLATION, EACCES
ERRORSHARINGVIOLATION, EACCES
ERRORNETWORKACCESS_DENIED, EACCES
ERRORCANNOTMAKE, EACCES
ERRORFAILI24, EACCES
ERRORDRIVELOCKED, EACCES
ERRORSEEKON_DEVICE, EACCES
ERRORNOTLOCKED, EACCES
ERRORLOCKFAILED, 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. 040standbyfailoverslotssync.pl does this:

my $standby1 = PostgreSQL::Test::Cluster->new('standby1');
$standby1->initfrombackup(

$primary, $backup_name,

has_streaming => 1,
has_restoring => 1);

And 046checkpontlogical_slot.pl does this:

my $standby = PostgreSQL::Test::Cluster->new('standby');
$standby->initfrombackup(

$primary, $backup_name,

has_streaming => 1,
has_restoring => 1);

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

On Jan 27, 2026, at 10:49 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

I wrote:

Robert Haas <robertmhaas@gmail.com> writes:
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.

D'oh: hamerkop doesn't run any TAP tests, let alone ones that require
--enable-injection-points. So that success proves nothing.

Our other Windows animals (drongo, fairywren, unicorn) seem to be
configured with -Dtap_tests=enabled, but nothing about injection
points, so they will also skip 046checkpointlogical_slot.
Seems like a bit of a blind spot in the buildfarm.

regards, tom lane