Horton

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

Greg Burd <greg@burd.me>

View thread View on postgr.es
From: "Greg Burd" <greg@burd.me>
To: "Andres Freund" <andres@anarazel.de>, "Robert Haas" <robertmhaas@gmail.com>
Cc: "Thomas Munro" <thomas.munro@gmail.com>, "Amit Kapila" <akapila@postgresql.org>, "PostgreSQL Hackers" <pgsql-hackers@lists.postgresql.org>, "Bryan Green" <dbryan.green@gmail.com>
Date: 2026-01-28T18:01:23Z
Lists: pgsql-hackers 
On Tue, Jan 27, 2026, at 1:17 PM, Andres Freund wrote:
> Hi,
>
> On 2026-01-27 12:42:51 -0500, Robert Haas wrote:
>> I tried sticking a pg_sleep(30) in just before starting the standby
>> node, and that didn't help, so it doesn't seem like it's a race
>> condition.
>
> Interesting.
>
> It could be worth trying to run the test in isolation, without all the other
> concurrent tests.
>
> Greg, have you tried to repro it interactively?

Nope, not yet.  I'm working on my ailing animals now and updated unicorn to include injection points.

-greg

> Bryan, you seem to have become the resident windows expert...
>
>
>> 2026-01-27 17:19:25.337 GMT startup[2488] LOG:  starting backup
>> recovery with redo LSN 0/2A000028, checkpoint LSN 0/2A000080, on
>> timeline ID 1
>> The system cannot find the file specified.
>> 2026-01-27 17:19:25.352 GMT startup[2488] DEBUG:  could not restore
>> file "00000001000000000000002A" from archive: child process exited
>> with exit code 1
>
> I think that must be a message from "copy" (which we seem to be using for
> restore_command on windows).
>
> I don't know why the standby is created with has_restoring => 1. But it
> shouldn't be related to the issue, I think?
>
> Greetings,
>
> Andres Freund

Commits

  1. Fix CI failure introduced in commit 851f6649cc.

  2. Prevent invalidation of newly synced replication slots.

  3. Prevent invalidation of newly created replication slots.