MIME-Version: 1.0
References: <1d12d2-67235980-35-19a406a0@63439497>
 <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>
 <CAA4eK1+VbBxYY-rG4B7Jq6TsYvdjt3d2nbUrs7p9-1sP5mH+sw@mail.gmail.com>
 <CAPpHfdvxqjE+RZdoOODQZAmQip6NpvSH40DuvVFWuf_00ek-yQ@mail.gmail.com>
 <1d97ec-6841b600-3-b7b4780@40747246>
 <CAA4eK1LvssAcp61qg957xRF0=K4xF0hfJQjQ6c9V7EGHSqraPg@mail.gmail.com>
 <28c8bf-68470780-3-51b29480@89454035>
 <CAPpHfdt77k3BqD=anh4b7UiRevfPOu2Hcf3rvSZXntxH+4G=Ug@mail.gmail.com>
 <fbc5d94e-6fbd-4a64-85d4-c9e284a58eb2@gmail.com>
 <CAPpHfdvPpg5VUTNOqfKSNx66ij3ZJNZbf4kn6SDcPkdq9FTvng@mail.gmail.com>
 <0a617d34-abc3-4090-92a5-ea15d45e36f6@gmail.com>
 <228607.1750003556@sss.pgh.pa.us>
 <CAPpHfdvJMe4i0_wp1tq2ZGSDKqUHKPwkfD_Y6KyJ3XQRFvc0cQ@mail.gmail.com>
 <OSCPR01MB1496667BEA93302F8903EE512F570A@OSCPR01MB14966.jpnprd01.prod.outlook.com>
 <CAPpHfdsdJ4YPTzH=cnany5_LjCNb_Z9e+Oucv53qYQHaHzJhag@mail.gmail.com>
 <CALDaNm3s-jpQTe1MshsvQ8GO=TLj233JCdkQ7uZ6pwqRVpxAdw@mail.gmail.com>
 <3f242e-68518380-11-78125f00@134027639>
In-Reply-To: <3f242e-68518380-11-78125f00@134027639>
From: Alexander Korotkov <aekorotkov@gmail.com>
Date: Tue, 17 Jun 2025 18:08:11 +0300
Message-ID: 
 <CAPpHfds0ScFbExsT+pnY7K0JGH6pFPHMOSfCOknC-1s7ahmRFA@mail.gmail.com>
Subject: Re: Slot's restart_lsn may point to removed WAL segment after hard
 restart unexpectedly
To: Vitaly Davydov <v.davydov@postgrespro.ru>
Cc: vignesh C <vignesh21@gmail.com>,
	"Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
 Tom Lane <tgl@sss.pgh.pa.us>,
	Alexander Lakhin <exclusion@gmail.com>,
 Amit Kapila <amit.kapila16@gmail.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>,
 Masahiko Sawada <sawada.mshk@gmail.com>,
	"tomas@vondra.me" <tomas@vondra.me>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAPpHfds0ScFbExsT%2BpnY7K0JGH6pFPHMOSfCOknC-1s7ahmRFA%40mail.gmail.com>
Precedence: bulk

Hi, Vitaly!

On Tue, Jun 17, 2025 at 6:02=E2=80=AFPM Vitaly Davydov <v.davydov@postgresp=
ro.ru> wrote:
> Thank you for reporting the issue.
>
> >While tracking buildfarm for one of other commits, I noticed this failur=
e:
> >TRAP: failed Assert("s->data.restart_lsn >=3D
> >s->last_saved_restart_lsn"), File:
> >"../pgsql/src/backend/replication/slot.c", Line: 1813, PID: 3945797
> >postgres: standby: checkpointer (ExceptionalCondition+0x83) [0x55fa69b79=
f5e]
> >postgres: standby: checkpointer
> >(InvalidateObsoleteReplicationSlots+0x53c) [0x55fa69982171]
> >postgres: standby: checkpointer (CreateCheckPoint+0x9ad) [0x55fa6971feb2=
]
>
> This assert was introduced in the patch. Now, I think, it is a wrong one.=
 Let me
> please explain one of the possible scenarios when it can be triggered. In=
 case
> of physical replication, when walsender receives a standby reply message,=
 it
> calls PhysicalConfirmReceivedLocation function which updates slots' resta=
rt_lsn
> from received flush_lsn value. This value may be older than the saved val=
ue. If
> it happens during checkpoint, after slot saving to disk, this assert will=
 be
> triggered, because last_saved_restart_lsn value may be lesser than the ne=
w
> restart_lsn value, updated from walsender.
>
> I propose to remove this assert.

Yes, but is it OK for restart_lsn to move backward?  That might mean
that if checkpoint happen faster than
PhysicalConfirmReceivedLocation(), then crash could cause this WAL
location to be unavailable.  Is that true?

Also, what do you think about proposed changes in [1]?  I wonder if it
could somehow decrease the coverage.

Links.
1. https://www.postgresql.org/message-id/OSCPR01MB149665B3F0629D10731B18E5A=
F570A%40OSCPR01MB14966.jpnprd01.prod.outlook.com

------
Regards,
Alexander Korotkov
Supabase