Horton

Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly

Alexander Korotkov <aekorotkov@gmail.com>

View thread
From: Alexander Korotkov <aekorotkov@gmail.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>, Amit Kapila <amit.kapila16@gmail.com>, Vitaly Davydov <v.davydov@postgrespro.ru>, Tom Lane <tgl@sss.pgh.pa.us>, Alexander Lakhin <exclusion@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Masahiko Sawada <sawada.mshk@gmail.com>, "tomas@vondra.me" <tomas@vondra.me>, vignesh C <vignesh21@gmail.com>
Date: 2025-06-25T21:50:29Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Update comment for ReplicationSlot.last_saved_restart_lsn

  2. Fix CheckPointReplicationSlots() with max_replication_slots == 0

  3. Remove excess assert from InvalidatePossiblyObsoleteSlot()

  4. Improve runtime and output of tests for replication slots checkpointing.

  5. Keep WAL segments by slot's last saved restart LSN

  6. Fix an assert in CheckPointReplicationSlots().

Attachments

On Wed, Jun 25, 2025 at 11:25 AM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> On Wed, Jun 25, 2025 at 1:18 PM Hayato Kuroda (Fujitsu)
> <kuroda.hayato@fujitsu.com> wrote:
> > Another idea is to call ReplicationSlotsComputeRequiredLSN() when at least one
> > of the restart_lsn is updated, like attached. I feel this could reduce the computation
> > bit more.
>
> Right, that makes sense, if there is nothing updated on disk then we
> can avoid computing this.

Good idea.  But I think we should associate the "updated" flag
directly to the fact that one slot (no matter logical or physical)
changed its last_saved_restart_lsn.  See the attached patch.  I'm
going to push it if no objections.

------
Regards,
Alexander Korotkov
Supabase