Re: pgsql: Prevent invalidation of newly synced replication slots.
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Amit Kapila <amit.kapila16@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-01-27T16:17:43Z
Lists: pgsql-hackers
On Tue, Jan 27, 2026 at 11:11 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > What's also puzzling is that what this test is doing seems to be > > totally standard. > > Yeah. I do notice something interesting when running it here: > 046_checkpoint_logical_slot_mike.log shows that we are triggering > quite a few checkpoints (via pg_switch_wal()) in quick succession > on the primary. I wonder if that is somehow tickling a Windows > filesystem restriction. Maybe, but it seems unlikely to me that this would mess up the standby, since it's a totally different node. What I kind of wonder is if somehow there's still a process that has backup_label open, or has closed it but not recently enough for Windows to unlock it. However, I don't see why that would affect this test case and not others. -- Robert Haas EDB: http://www.enterprisedb.com
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