MIME-Version: 1.0
From: Ayush Tiwari <ayushtiwari.slg01@gmail.com>
Date: Mon, 16 Mar 2026 21:39:30 +0530
Message-ID: 
 <CAJTYsWXd4s0eYnN+80ND1t1q6gabk2dbN-w-K6AJj44nz+Xd9Q@mail.gmail.com>
Subject: Proposal: Prevent Primary/Standby SLRU divergence during MultiXact
 truncation
To: pgsql-hackers@postgresql.org
Content-Type: multipart/mixed; boundary="0000000000004be1d2064d2672a9"
Archived-At: 
 <https://www.postgresql.org/message-id/CAJTYsWXd4s0eYnN%2B80ND1t1q6gabk2dbN-w-K6AJj44nz%2BXd9Q%40mail.gmail.com>
Precedence: bulk

--0000000000004be1d2064d2672a9
Content-Type: multipart/alternative; boundary="0000000000004be1d0064d2672a7"

--0000000000004be1d0064d2672a7
Content-Type: text/plain; charset="UTF-8"

Hi Hackers,

Looking at the MultiXact truncation behavior and reading through the recent
thread regarding the 17.8 standby crashing during WAL replay (commit
8ba61bc), we noticed an architectural edge case that seems to cause a
silent primary/standby SLRU divergence. I'd like to ask if this is a known
accepted risk or if a patch to reorder this logic is worth exploring.

The Issue:
In TruncateMultiXact(), we write the truncation WAL record
(WriteMTruncateXlogRec) before we actually perform the truncation via
PerformOffsetsTruncation() -> SimpleLruTruncate().

The problem arises from the "apparent wraparound" safety check inside
SimpleLruTruncate(). If SlruScanDirectory() detects an apparent wraparound,
SimpleLruTruncate() safely bails out and skips unlinking the SLRU segments
on the primary, logging: could not truncate directory "%s": apparent
wraparound.

However, the WAL record for the truncation has already been flushed.
Standbys replay this TRUNCATE_ID WAL record and blindly delete their SLRU
segments. At this point, the primary and standby have diverged.

The Impact:
If the standby is subsequently promoted to primary, any attempt to access
rows holding those older MultiXact IDs (which the original primary decided
to keep) will throw a FATAL: could not access status of transaction error,
effectively resulting in data loss / inaccessible rows for the user.

While the recent commits address the immediate standby crash involving
latest_page_number during multixact_redo(), they don't seem to prevent the
primary from emitting a "false" WAL truncation record when it abandons its
own truncation.

Proposed Approach:
It seems safer to only emit the WAL record if we are guaranteed to follow
through with the truncation. We could modify SimpleLruTruncate() to perform
its safety checks first and return a boolean indicating whether the
truncation is safe to proceed. TruncateMultiXact() would then only call
WriteMTruncateXlogRec() and proceed with physical deletion if the check
passes.

I have attached a rough draft patch illustrating this sequence change.

Is this a scenario the community has already considered, or is this
reordering something that should be explored further to harden standby
reliability?

PS. Also, noticed this to be the case in clog.c file

Thanks for your time.

Regards,
Ayush

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

<div dir=3D"ltr">Hi Hackers,<br><br>Looking at the MultiXact truncation beh=
avior and reading through the recent thread regarding the 17.8 standby cras=
hing during WAL replay (commit 8ba61bc), we noticed an architectural edge c=
ase that seems to cause a silent primary/standby SLRU divergence. I&#39;d l=
ike to ask if this is a known accepted risk or if a patch to reorder this l=
ogic is worth exploring.<br><br>The Issue:<br>In TruncateMultiXact(), we wr=
ite the truncation WAL record (WriteMTruncateXlogRec) before we actually pe=
rform the truncation via PerformOffsetsTruncation() -&gt; SimpleLruTruncate=
().<br><br>The problem arises from the &quot;apparent wraparound&quot; safe=
ty check inside SimpleLruTruncate(). If SlruScanDirectory() detects an appa=
rent wraparound, SimpleLruTruncate() safely bails out and skips unlinking t=
he SLRU segments on the primary, logging: could not truncate directory &quo=
t;%s&quot;: apparent wraparound.<br><br>However, the WAL record for the tru=
ncation has already been flushed. Standbys replay this TRUNCATE_ID WAL reco=
rd and blindly delete their SLRU segments. At this point, the primary and s=
tandby have diverged.<br><br>The Impact:<br>If the standby is subsequently =
promoted to primary, any attempt to access rows holding those older MultiXa=
ct IDs (which the original primary decided to keep) will throw a FATAL: cou=
ld not access status of transaction error, effectively resulting in data lo=
ss / inaccessible rows for the user.<br><br>While the recent commits addres=
s the immediate standby crash involving latest_page_number during multixact=
_redo(), they don&#39;t seem to prevent the primary from emitting a &quot;f=
alse&quot; WAL truncation record when it abandons its own truncation.<br><b=
r>Proposed Approach:<br>It seems safer to only emit the WAL record if we ar=
e guaranteed to follow through with the truncation. We could modify SimpleL=
ruTruncate() to perform its safety checks first and return a boolean indica=
ting whether the truncation is safe to proceed. TruncateMultiXact() would t=
hen only call WriteMTruncateXlogRec() and proceed with physical deletion if=
 the check passes.<br><br>I have attached a rough draft patch illustrating =
this sequence change.<br><br>Is this a scenario the community has already c=
onsidered, or is this reordering something that should be explored further =
to harden standby reliability?<br><br>PS. Also, noticed this to be the case=
 in clog.c file<br><br>Thanks for your time.<br><br>Regards,<br>Ayush</div>

--0000000000004be1d0064d2672a7--

--0000000000004be1d2064d2672a9
Content-Type: application/octet-stream;
	name="v1-prevent-multixact-slru-divergence 2.patch"
Content-Disposition: attachment;
	filename="v1-prevent-multixact-slru-divergence 2.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mmtdm4ym0>
X-Attachment-Id: f_mmtdm4ym0

RnJvbSA5Yjg4MzBmZTM1YWM5YTJjMmVmYWJjMWU5MTI0NGU4YWJjZDEyMzQ1IE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQ0KRnJvbTogQXl1c2ggVGl3YXJpIDxheXVzaHRpd2FyaS5zbGcwMUBnbWFp
bC5jb20+DQpEYXRlOiBNb24sIDE2IE1hciAyMDI2IDEyOjAwOjAwICswMDAwDQpTdWJqZWN0OiBb
RHJhZnQgUGF0Y2ggdjFdIFByZXZlbnQgU0xSVSBkaXZlcmdlbmNlIGJ5IGNoZWNraW5nIHdyYXBh
cm91bmQgYmVmb3JlIFdBTA0KIGZsdXNoDQoNCkluIFRydW5jYXRlTXVsdGlYYWN0KCksIGlmIFNp
bXBsZUxydVRydW5jYXRlKCkgZW5jb3VudGVycyBhbiBhcHBhcmVudA0Kd3JhcGFyb3VuZCwgaXQg
YWJvcnRzIHRoZSB0cnVuY2F0aW9uIHNhZmVseS4gSG93ZXZlciwgdGhlIFRSVU5DQVRFX0lEDQpX
QUwgcmVjb3JkIGhhcyBhbHJlYWR5IGJlZW4gZW1pdHRlZC4gU3RhbmRieXMgYmxpbmRseSByZXBs
YXkgdGhpcyByZWNvcmQNCmFuZCBkZWxldGUgdGhlaXIgU0xSVSBzZWdtZW50cy4NClRoaXMgcGF0
Y2ggb3V0bGluZXMgYSBzdHJ1Y3R1cmFsIHJlb3JkZXJpbmcgc28gd2Ugb25seSBlbWl0IHRoZQ0K
VFJVTkNBVEUgV0FMIHJlY29yZCBpZiB3ZSBhcmUgZ3VhcmFudGVlZCB0byBmb2xsb3cgdGhyb3Vn
aC4NCg0KLS0tDQogc3JjL2JhY2tlbmQvYWNjZXNzL3RyYW5zYW0vbXVsdGl4YWN0LmMgfCAxNiAr
KysrKysrKysrKysrLS0tDQogMSBmaWxlIGNoYW5nZWQsIDEzIGluc2VydGlvbnMoKyksIDMgZGVs
ZXRpb25zKC0pDQoNCmRpZmYgLS1naXQgYS9zcmMvYmFja2VuZC9hY2Nlc3MvdHJhbnNhbS9tdWx0
aXhhY3QuYyBiL3NyYy9iYWNrZW5kL2FjY2Vzcy90cmFuc2FtL211bHRpeGFjdC5jDQppbmRleCBh
MWIyYzNkNGUuLmY1ZzZoN2k4aiAxMDA2NDQNCi0tLSBhL3NyYy9iYWNrZW5kL2FjY2Vzcy90cmFu
c2FtL211bHRpeGFjdC5jDQorKysgYi9zcmMvYmFja2VuZC9hY2Nlc3MvdHJhbnNhbS9tdWx0aXhh
Y3QuYw0KQEAgLTI5ODAsMTAgKzI5ODAsMjAgQEAgVHJ1bmNhdGVNdWx0aVhhY3QoTXVsdGlYYWN0
SWQgbmV3T2xkZXN0TXVsdGksIE9pZCBuZXdPbGRlc3RNdWx0aURCKQ0KIAlBc3NlcnQoKE15UHJv
Yy0+ZGVsYXlDaGtwdEZsYWdzICYgREVMQVlfQ0hLUFRfU1RBUlQpID09IDApOw0KIAlNeVByb2Mt
PmRlbGF5Q2hrcHRGbGFncyB8PSBERUxBWV9DSEtQVF9TVEFSVDsNCiANCi0JLyogV0FMIGxvZyB0
cnVuY2F0aW9uICovDQotCVdyaXRlTVRydW5jYXRlWGxvZ1JlYyhuZXdPbGRlc3RNdWx0aURCLCBu
ZXdPbGRlc3RNdWx0aSwgbmV3T2xkZXN0T2Zmc2V0KTsNCisJLyogDQorCSAqIFRPRE8vRFJBRlQ6
IA0KKwkgKiBXZSBzaG91bGQgY2hlY2sgaWYgU2ltcGxlTHJ1VHJ1bmNhdGUoKSB3aWxsIGFib3J0
IGR1ZSB0byANCisJICogYXBwYXJlbnQgd3JhcGFyb3VuZCAqYmVmb3JlKiBmbHVzaGluZyB0aGUg
V0FMLg0KKwkgKiANCisJICogaWYgKFNpbXBsZUxydUNoZWNrV3JhcGFyb3VuZChNdWx0aVhhY3RP
ZmZzZXRDdGwsIE11bHRpWGFjdElkVG9PZmZzZXRQYWdlKG5ld09sZGVzdE11bHRpKSkgJiYNCisJ
ICogICAgIFNpbXBsZUxydUNoZWNrV3JhcGFyb3VuZChNdWx0aVhhY3RNZW1iZXJDdGwsIE11bHRp
WGFjdElkVG9NZW1iZXJQYWdlKG5ld09sZGVzdE9mZnNldCkpKQ0KKwkgKiB7DQorCSAqICAgICAv
LyBXQUwgbG9nIHRydW5jYXRpb24NCisJICogICAgIFdyaXRlTVRydW5jYXRlWGxvZ1JlYyhuZXdP
bGRlc3RNdWx0aURCLCBuZXdPbGRlc3RNdWx0aSwgbmV3T2xkZXN0T2Zmc2V0KTsNCisJICogICAg
IC8vIHVwZGF0ZSBpbiBhcnJheSBsaW1pdHMsIGV0Yy4NCisJICogICAgIC8vIHBlcmZvcm0gcGh5
c2ljYWwgdHJ1bmNhdGlvbg0KKwkgKiB9DQorCSAqLw0KIA0KIAkvKg0KIAkgKiBVcGRhdGUgaW4t
bWVtb3J5IGxpbWl0cyBiZWZvcmUgcGVyZm9ybWluZyB0aGUgdHJ1bmNhdGlvbiwgd2hpbGUgaW5z
aWRlDQotLSANCjIuMzQuMQ0K
--0000000000004be1d2064d2672a9--