Re: pgsql: Prevent invalidation of newly synced replication slots.
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Amit Kapila <akapila@postgresql.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-01-27T16:16:13Z
Lists: 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...
Commits
-
Fix CI failure introduced in commit 851f6649cc.
- 1c60f7236368 18.2 landed
- 3a98f989e8e5 19 (unreleased) landed
- 9649f1adfdee 17.8 landed
-
Prevent invalidation of newly synced replication slots.
- 851f6649cc18 19 (unreleased) cited
-
Prevent invalidation of newly created replication slots.
- 006dd4b2e5b3 19 (unreleased) cited