From: "Vitaly Davydov" <v.davydov@postgrespro.ru>
In-Reply-To: 
 <CAA4eK1LvssAcp61qg957xRF0=K4xF0hfJQjQ6c9V7EGHSqraPg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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>
 <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>
Date: Mon, 09 Jun 2025 19:09:58 +0300
Cc: "Alexander Korotkov" <aekorotkov@gmail.com>,
 "pgsql-hackers" <pgsql-hackers@postgresql.org>,
 "Masahiko Sawada" <sawada.mshk@gmail.com>, tomas@vondra.me
To: "Amit Kapila" <amit.kapila16@gmail.com>
MIME-Version: 1.0
Message-ID: <28c8bf-68470780-3-51b29480@89454035>
Subject: =?utf-8?q?Re=3A?= Slot's =?utf-8?q?restart=5Flsn?= may point to
 removed WAL
 segment after hard restart unexpectedly
User-Agent: SOGoMail 5.12.0
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/28c8bf-68470780-3-51b29480%4089454035>
Precedence: bulk

Hi Amit,

> I think we can use this approach for HEAD and probably keep the
> previous idea for backbranches. Keeping some value in shared=5Fmemory
> per slot sounds risky to me in terms of introducing new bugs.

Not sure, what kind of problems may occur. I propose to allocate in shm=
em an
array of last=5Fsaved=5Frestart=5Flsn like below which is not a part of=
 the public
api (see below). It will be allocated and deallocated in shmem the same=
 way as
ReplicationSlotCtlData. I can prepare a patch, if needed.

typedef struct ReplicationSlotCtlDataExt {
	XLogRecPtr last=5Fsaved=5Frestart=5Flsn[1];
} ReplicationSlotCtlDataExt;

> Yeah, but with physical slots, it is possible that the slot's xmin
> value is pointing to some value, say 700 (after restart), but vacuum
> would have removed tuples from transaction IDs greater than 700 as
> explained in email [1].

I think, we have no xmin problem for physical slots. The xmin values of
physical slots are used to process HSF messages. If I correctly underst=
ood what
you mean, you are telling about the problem which is solved by hot stan=
dby
feedback messages. This message is used to disable tuples vacuuming on =
the
primary to avoid delete conflicts on the replica in queries (some queri=
es may
select some tuples which were vacuumed on the primary and deletions are
replicated to the standby). If the primary receives a HSF message after=
 slot
saving, I believe, it is allowable if autovacuum cleans tuples with xmi=
n later
than the last saved value. If the primary restarts, the older value wil=
l be
loaded but the replica already confirmed the newer value. Concerning re=
plica,
it is the obligation of the replica to send such HSF xmin that will sur=
vive
replica's immediate restart.

>> Taking into account these thoughts, I can't see any problems with th=
e alternative
>> patch where oldest wal lsn is calculated only in checkpoint.
>>
>The alternative will needlessly prevent removing WAL segments in some
>cases when logical slots are in use.

IMHO, I'm not sure, it will significantly impact the wal removal. We re=
move WAL
segments only in checkpoint. The alternate solution gets the oldest WAL=
 segment
at the beginning of checkpoint, then saves dirty slots to disk, and rem=
oves old
WAL segments at the end of checkpoint using the oldest WAL segment obta=
ined at
the beginning of checkpoint. The alternate solution may not be so effec=
tive
in terms of WAL segments removal, if a logical slot is advanced during
checkpoint, but I do not think it is a significant issue. From the othe=
r hand,
the alternate solution simplifies the logic of WAL removal, backward co=
mpatible
(avoids addition new in-memory states), decreases the number of locks i=
n
ReplicationSlotsComputeRequiredLSN - no need to recalculate oldest slot=
s'
restart lsn every time when a slot is advanced.

With best regards,
Vitaly