Horton

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

Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>

View thread
From: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
To: 'Alexander Korotkov' <aekorotkov@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>
Cc: "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-26T03:46:44Z
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().

Dear Alexander,
> 
> 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.

+		/*
+		 * Track if we're going to update slot's last_saved_restart_lsn.
+		 * We need this to know if we need to recompute the required LSN.
+		 */
+		if (s->last_saved_restart_lsn != s->data.restart_lsn)
+			last_saved_restart_lsn_updated = true;

I feel no need to set to true if last_saved_restart_lsn_updated is already true.
Other than that it's OK for me.

Best regards,
Hayato Kuroda
FUJITSU LIMITED