MIME-Version: 1.0
References: <1d12d2-67235980-35-19a406a0@63439497>
 <683f3c82-d38e-436d-88fd-27722af62005@vondra.me>
 <8679fea7-94ce-4a52-8e48-1a8cd0857fcb@vondra.me>
 <ec90c6ed-92eb-4fa5-861b-af6167f04c43@vondra.me>
 <e3ac0535-e7a2-4a96-9b36-9f765e9cfec5@vondra.me>
 <135e8-675c4600-21-304d7f40@228322535>
 <1538a2-67c5c700-7-77ec5a80@179382871>
 <CAPpHfdvQPndPMbPvrHqUYbi_HnTZxxaZ4cafvF+9Mx56v07W-w@mail.gmail.com>
 <27589a-680a4b80-6d-6e07880@117064404>
 <CAPpHfdujSUM6de2ZD6gP_3vjUonHgiqh7StPZ5AQz-=4-qhuzA@mail.gmail.com>
 <CAD21AoAbP8NJN3UZXA=RMB_LMwWFDwkV6Erzf7WpAa=jqs0_6A@mail.gmail.com>
 <CAPpHfdtgwhFFpb8v8x2Humdj3F_DjaeBWY_h20g-Owh5tMArCA@mail.gmail.com>
 <CAD21AoDp4Zabk49G94TdWrthfv+0mhHLA6yw-AJxxRSFWPep+g@mail.gmail.com>
 <3ea6a1-68150580-1-7b53be0@80017081>
 <CAPpHfdvpcboCAxbj+xPmCWNRZxG=JwW3qRsz4No_OvP3j03ERg@mail.gmail.com>
 <309f08-682ca380-25-139bf240@62751029>
 <CAPpHfduDLCrQ=vp1KBJu5fnSzgQp9ebGRV7i2poHK9VthwaL7g@mail.gmail.com>
 <CAPpHfdutKQxpm-gJgiZRb2ouKC9+HZx3fG3F00zd=xdxDidm_g@mail.gmail.com>
 <CAA4eK1+eebaviZ9TCU4DHAOZzRRbWe0HgdjjQ1VVu7P_pEsiYQ@mail.gmail.com>
 <CAPpHfdsk9_mrZaR_twwe6ntFUYCwu9SM1t4n6SmWNTZDZGefoQ@mail.gmail.com>
 <CAA4eK1KMaPA5jir_SFu+qr3qu55OOdFWVZpuUkqTSGZ9fyPpHA@mail.gmail.com>
 <2c1d-68344100-b7-3411b8c0@256938178>
 <CAA4eK1LmVoZ8jm5Jt3DERN9Z=y6L6xj5O0asw0smWw31Y8KfVw@mail.gmail.com>
 <CAPpHfdtp61pSt72KxxOnnV_Oj4OTAiKYCSTek0Pm87hVDod4Bg@mail.gmail.com>
 <CAA4eK1Lmd-stXWrNqX9iXugjY=ahhe7zRfyq+-vN512xvF4G2w@mail.gmail.com>
 <CAPpHfdsTiYQPywr4yeqVhUtA+eFdqisqcAOiTb+kiYhi9EVEvw@mail.gmail.com>
 <CAPpHfdvk-nfu5xzJyPArxWctofWPR+1L9uJ+yyWFA34n6b5rGQ@mail.gmail.com>
 <CAA4eK1Ladnm40UO-YC+c7eBYqjyFQSwg0dn1w_CiaMoBTsJUDA@mail.gmail.com>
 <CAPpHfduX--KKX853UwaJ8Cjo5bxbh19V_+McKQ3p9aS6b8T1Wg@mail.gmail.com>
In-Reply-To: 
 <CAPpHfduX--KKX853UwaJ8Cjo5bxbh19V_+McKQ3p9aS6b8T1Wg@mail.gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Mon, 2 Jun 2025 17:23:43 +0530
Message-ID: 
 <CAA4eK1+VbBxYY-rG4B7Jq6TsYvdjt3d2nbUrs7p9-1sP5mH+sw@mail.gmail.com>
Subject: Re: Slot's restart_lsn may point to removed WAL segment after hard
 restart unexpectedly
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: Vitaly Davydov <v.davydov@postgrespro.ru>,
 pgsql-hackers <pgsql-hackers@postgresql.org>,
	Masahiko Sawada <sawada.mshk@gmail.com>, tomas@vondra.me
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAA4eK1%2BVbBxYY-rG4B7Jq6TsYvdjt3d2nbUrs7p9-1sP5mH%2Bsw%40mail.gmail.com>
Precedence: bulk

On Thu, May 29, 2025 at 5:29=E2=80=AFPM Alexander Korotkov <aekorotkov@gmai=
l.com> wrote:
>
> On Tue, May 27, 2025 at 2:26=E2=80=AFPM Amit Kapila <amit.kapila16@gmail.=
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.
>

This appears to be a better direction than the other patch, at least
for HEAD. I noticed a few points while looking at the patch.

1. restart_lsn_flushed: Can we name it as last_saved_restart_lsn based
on existing variable last_saved_confirmed_flush?
2. There are no comments as to why this is considered only for
persistent slots when CheckPointReplicationSlots doesn't have any such
check.
3. Please see if it makes sense to copy it in the copy_replication_slot.

Apart from these, I am not sure if there are still any pending
comments in the thread to be handled for this patch, so please see to
avoid missing anything.

> > 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?
>

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.

--=20
With Regards,
Amit Kapila.