Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly
Date
Msg-id CAA4eK1LqeHVnem1iF+4Jy2M36ZyN57szJdPv3TjnQr+ksZ_Qqw@mail.gmail.com
Whole thread Raw
In response to Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly  ("Vitaly Davydov" <v.davydov@postgrespro.ru>)
List pgsql-hackers
On Tue, Jun 3, 2025 at 6:51 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
>
> >
> > As per my understanding, for logical slots, effective_xmin is only set
> > during the initial copy phase (or say if one has to export a
> > snapshot), after that, its value won't change. Please read the
> > comments in CreateInitDecodingContext() where we set its value. If you
> > still have questions about it, we can discuss further.
>
> OK, thank you for the clarification.   I've read the comments in
> CreateInitDecodingContext() as you suggested.  All of above makes me
> think *_xmin fields are handled properly.
>

Yes, they handled properly for logical slots, but there is no similar
safety mechanism for physical slots.

One minor comment:
+
+ /* Latest restart_lsn that has been flushed to disk. For persistent slots
+ * the flushed LSN should be taken into account when calculating the oldest

This doesn't follow our practice for multi-line comments.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Remaining dependency on setlocale()
Next
From: Peter Eisentraut
Date:
Subject: Re: Update Windows CI Task Names: Server 2022 + VS 2022 Upgrade