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

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

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

To: 'Amit Kapila' <amit.kapila16@gmail.com>, Alexander Korotkov <aekorotkov@gmail.com>

Cc: Vitaly Davydov <v.davydov@postgrespro.ru>, vignesh C <vignesh21@gmail.com>, 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>

Date: 2025-06-29T06:22:30Z

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 →

Update comment for ReplicationSlot.last_saved_restart_lsn
- 0810fbb02dbe 19 (unreleased) landed
Fix CheckPointReplicationSlots() with max_replication_slots == 0
- 7195c804bd12 18.0 landed
Remove excess assert from InvalidatePossiblyObsoleteSlot()
- 70d8a91f82f1 18.0 landed
Improve runtime and output of tests for replication slots checkpointing.
- 5ed50f9386f0 17.6 landed
- 4464fddf7b50 18.0 landed
Keep WAL segments by slot's last saved restart LSN
- ca307d5cec90 18.0 landed
Fix an assert in CheckPointReplicationSlots().
- d1ffcc7fa3c5 17.0 cited

Attachments

0001-Update-comment-for-last_saved_restart_lsn.patch (application/octet-stream) patch 0001

Dear hackers,

Thanks everyone who are working on the bug. IIUC the remained task is
to add code comments for avoiding the same mistake again described here:

> Sounds reasonable. As per analysis till now, it seems removal of new
> assert is correct and we just need to figure out the reason in all
> failure cases as to why the physical slot's restart_lsn goes backward,
> and then add a comment somewhere to ensure that we don't repeat a
> similar mistake in the future.

I've wrote a draft for that. How do you think?


Best regards,
Hayato Kuroda
FUJITSU LIMITED