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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: pgsql: Prevent invalidation of newly synced replication slots.
Date: 2026-01-27 16:17:43
Message-ID: CA+TgmobXMhXFYM=mJ51f5PRFuj7eR9zn68Bvjndjz-k+daSotg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

On Tue, Jan 27, 2026 at 11:11 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Andres Freund 2026-01-27 16:37:56 Re: pgsql: Prevent invalidation of newly synced replication slots.
Previous Message Andres Freund 2026-01-27 16:17:31 Re: pgsql: Prevent invalidation of newly synced replication slots.

Browse pgsql-hackers by date

  From Date Subject
Next Message Srirama Kucherlapati 2026-01-27 16:21:12 RE: AIX support
Previous Message Andres Freund 2026-01-27 16:17:31 Re: pgsql: Prevent invalidation of newly synced replication slots.