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: Amit Kapila <amit.kapila16@gmail.com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, 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-07-18T11:41:31Z
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().

On Fri, Jul 18, 2025 at 1:48 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> On Fri, Jul 18, 2025 at 4:15 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> >
> > On Sun, Jun 29, 2025 at 9:22 AM Hayato Kuroda (Fujitsu)
> > <kuroda.hayato@fujitsu.com> wrote:
> > > 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?
> >
> > Looks good to me.  I'm going to push this if no objections.
> >
>
> As discussed earlier, it is a good idea to add comments in this area.
> But as this is for pre-existing cases, won't it be better to start a
> new thread explaining the cases and a patch? We may get feedback from
> others as well.

OK, done.

https://www.postgresql.org/message-id/CAPpHfdvuyMrUg0Vs5jPfwLOo1M9B-GP5j_My9URnBX0B%3DnrHKw%40mail.gmail.com

------
Regards,
Alexander Korotkov
Supabase