MIME-Version: 1.0
References: 
 <CAJTYsWXd4s0eYnN+80ND1t1q6gabk2dbN-w-K6AJj44nz+Xd9Q@mail.gmail.com>
 <e1787b17-dc93-4621-a5a1-c713d1ac6a1b@iki.fi>
In-Reply-To: <e1787b17-dc93-4621-a5a1-c713d1ac6a1b@iki.fi>
From: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Date: Tue, 17 Mar 2026 20:37:26 +0530
Message-ID: 
 <CAJTYsWV1qSPVYzfZn0OXD661xReuKvVT0ccPuRb1PDv6MVjRPw@mail.gmail.com>
Subject: Re: Proposal: Prevent Primary/Standby SLRU divergence during
 MultiXact truncation
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: pgsql-hackers@postgresql.org
Content-Type: multipart/alternative; boundary="0000000000003193db064d39b282"
Archived-At: 
 <https://www.postgresql.org/message-id/CAJTYsWV1qSPVYzfZn0OXD661xReuKvVT0ccPuRb1PDv6MVjRPw%40mail.gmail.com>
Precedence: bulk

--0000000000003193db064d39b282
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Thank you for the response.

On Tue, 17 Mar 2026 at 03:40, Heikki Linnakangas <hlinnaka@iki.fi> wrote:

>
> Replaying the record will perform the same sanity checks against
> wraparound as the primary does.
>
> Hmm, although why did I not apply commit 817f74600d to 'master', only
> backbranches? The bug that it fixed was related to minor version
> upgrade, and thus it was not needed on 'master', but the code change
> would nevertheless make a lot of sense on 'master' too.
>

Agreed, once 817f74600d is on master the standby would honestly evaluate
the SimpleLruTruncate wraparound backstop instead of bypassing it.

However, the backstop is documented as catching "wraparound bugs elsewhere
in SLRU handling." If such a bug corrupts latest_page_number on the
primary, the standby =E2=80=94 which derives its latest_page_number indepen=
dently
from ZERO_OFF_PAGE replay and StartupMultiXact() =E2=80=94 would not share =
the same
corruption. The primary would skip the truncation, but the standby would
see a healthy latest_page_number and proceed.


> Have you been able to reproduce that?
>

I have reproduced the primary-side condition on an unmodified tree using
gdb in batch mode: attach to the VACUUM backend after
WriteMTruncateXlogRec() returns, corrupt latest_page_number, and resume.
The primary logs "apparent wraparound" and skips the physical deletion,
while pg_waldump confirms the TRUNCATE_ID record is present in the WAL. I
have not yet set up a streaming replica to demonstrate end-to-end
divergence and promotion failure.

>
> I agree that would probably be better. I'm not sure how straightforward
> it will be to implement though, I wouldn't want to add much extra code
> just for this.
>

One approach that might keep the footprint small: we could inline the same
PagePrecedes check that SimpleLruTruncate uses directly in
TruncateMultiXact(), before START_CRIT_SECTION(). Something like:

if (MultiXactOffsetCtl->PagePrecedes(
        pg_atomic_read_u64(&MultiXactOffsetCtl->shared->latest_page_number)=
,
        MultiXactIdToOffsetPage(PreviousMultiXactId(newOldestMulti))) ||
    MultiXactMemberCtl->PagePrecedes(
        pg_atomic_read_u64(&MultiXactMemberCtl->shared->latest_page_number)=
,
        MXOffsetToMemberPage(newOldestOffset)))
{
    ereport(LOG,
            (errmsg("skipping multixact truncation due to apparent
wraparound")));
    LWLockRelease(MultiXactTruncationLock);
    return;
}

No new functions, no changes to slru.c or the replay path =E2=80=94 just th=
e same
condition evaluated earlier so we never enter the critical section or write
WAL for a truncation that won't be carried out. Does this seem like a
reasonable direction?

Regards,
Ayush

--0000000000003193db064d39b282
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,<br><br>Thank you for the response.</div><br><div =
class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail=
_attr">On Tue, 17 Mar 2026 at 03:40, Heikki Linnakangas &lt;<a href=3D"mail=
to:hlinnaka@iki.fi">hlinnaka@iki.fi</a>&gt; wrote:</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
<br>
Replaying the record will perform the same sanity checks against <br>
wraparound as the primary does.<br>
<br>
Hmm, although why did I not apply commit 817f74600d to &#39;master&#39;, on=
ly <br>
backbranches? The bug that it fixed was related to minor version <br>
upgrade, and thus it was not needed on &#39;master&#39;, but the code chang=
e <br>
would nevertheless make a lot of sense on &#39;master&#39; too.<br></blockq=
uote><div><br></div>Agreed, once 817f74600d is on master the standby would =
honestly evaluate the SimpleLruTruncate wraparound backstop instead of bypa=
ssing it.<br><br><div>However, the backstop is documented as catching &quot=
;wraparound bugs elsewhere in SLRU handling.&quot; If such a bug corrupts l=
atest_page_number on the primary, the standby =E2=80=94 which derives its l=
atest_page_number independently from ZERO_OFF_PAGE replay and StartupMultiX=
act() =E2=80=94 would not share the same corruption. The primary would skip=
 the truncation, but the standby would see a healthy latest_page_number and=
 proceed.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Have you been able to reproduce that?<br></blockquote><div><br></div><div>I=
 have reproduced the primary-side condition on an unmodified tree using gdb=
 in batch mode: attach to the VACUUM backend after WriteMTruncateXlogRec() =
returns, corrupt latest_page_number, and resume. The primary logs &quot;app=
arent wraparound&quot; and skips the physical deletion, while pg_waldump co=
nfirms the TRUNCATE_ID record is present in the WAL. I have not yet set up =
a streaming replica to demonstrate end-to-end divergence and promotion fail=
ure.=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0=
px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I agree that would probably be better. I&#39;m not sure how straightforward=
 <br>
it will be to implement though, I wouldn&#39;t want to add much extra code =
<br>
just for this.<br></blockquote><div><br></div><div>One approach that might =
keep the footprint small: we could inline the same PagePrecedes check that =
SimpleLruTruncate uses directly in TruncateMultiXact(), before START_CRIT_S=
ECTION(). Something like:<br><br>if (MultiXactOffsetCtl-&gt;PagePrecedes(<b=
r>=C2=A0 =C2=A0 =C2=A0 =C2=A0 pg_atomic_read_u64(&amp;MultiXactOffsetCtl-&g=
t;shared-&gt;latest_page_number),<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 MultiXactI=
dToOffsetPage(PreviousMultiXactId(newOldestMulti))) ||<br>=C2=A0 =C2=A0 Mul=
tiXactMemberCtl-&gt;PagePrecedes(<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 pg_atomic_=
read_u64(&amp;MultiXactMemberCtl-&gt;shared-&gt;latest_page_number),<br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 MXOffsetToMemberPage(newOldestOffset)))<br>{<br>=
=C2=A0 =C2=A0 ereport(LOG,<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (er=
rmsg(&quot;skipping multixact truncation due to apparent wraparound&quot;))=
);<br>=C2=A0 =C2=A0 LWLockRelease(MultiXactTruncationLock);<br>=C2=A0 =C2=
=A0 return;<br>}<br><br>No new functions, no changes to slru.c or the repla=
y path =E2=80=94 just the same condition evaluated earlier so we never ente=
r the critical section or write WAL for a truncation that won&#39;t be carr=
ied out. Does this seem like a reasonable direction?<br><br>Regards,<br>Ayu=
sh</div></div></div>

--0000000000003193db064d39b282--