| 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
| 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. |
| 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. |