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

From Thomas Munro
Subject Re: pgsql: Prevent invalidation of newly synced replication slots.
Date
Msg-id CA+hUKGJotCdMdhrwVST4xbsPzr-csDgzveNhKu4UAXEmCDJ4iA@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 Wed, Jan 28, 2026 at 3:59 AM Robert Haas <robertmhaas@gmail.com> wrote:
> I imagine this is going to break CI for everybody else too, as well as cfbot.

Just by the way, on that last point, we trained cfbot to watch out for
CI pass/fail in this account:

https://github.com/postgres/postgres/commits/master/

and then use the most recent pass as the base commit when applying
patches to make test branches.  So if master is broken for a while, it
no longer takes all the cfbot runs with it.  Mentioning just in case
anyone is confused by that...

As for what's happening... hmm, there are a few holes in the "shared
locking" stuff you get with the flags we use.  For example you can't
unlink a directory that contains a file that has been unlinked but
someone still holds open.  Doesn't seem to be the case here.  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...



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: RepOrigin vs. replorigin
Next
From: Andres Freund
Date:
Subject: Re: pgsql: Prevent invalidation of newly synced replication slots.