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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
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:11:08
Message-ID: 547219.1769530268@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Thomas Munro 2026-01-27 16:16:13 Re: pgsql: Prevent invalidation of newly synced replication slots.
Previous Message Robert Haas 2026-01-27 15:51:58 Re: pgsql: Prevent invalidation of newly synced replication slots.

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2026-01-27 16:14:12 Re: Extended Statistics set/restore/clear functions.
Previous Message Robert Haas 2026-01-27 15:55:23 Re: pg_waldump: support decoding of WAL inside tarfile