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

On Tue, May 27, 2025 at 2:26 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> Yeah, we should be able to change ABI during beta, but I can't comment
> on the idea of effective_restart_lsn without seeing the patch or a
> detailed explanation of this idea.

Could you, please, check the patch [1]. It implements this idea
except it names new field restart_lsn_flushed instead of
effective_restart_lsn.

> Now, you see my point related to restart_lsn computation for logical
> slots, it is better to also do some analysis of the problem related to
> xmin I have highlighted in one of my previous emails [1]. I see your
> response to it, but I feel someone needs to give it a try by writing a
> test and see the behavior. I am saying because logical slots took
> precaution of flushing to disk before updating shared values of xmin
> for a reason, whereas similar precautions are not taken for physical
> slots, so there could be a problem with that computation as well.

I see LogicalConfirmReceivedLocation() performs correctly while
updating effective_catalog_xmin only after syncing the slot to the
disk. I don't see how effective_xmin gets updates with the logical
replication progress though. Could you get me some clue on this,
please?

Links.
1. https://www.postgresql.org/message-id/1538a2-67c5c700-7-77ec5a80%40179382871

------
Regards,
Alexander Korotkov
Supabase