public inbox for [email protected]  

help / color / mirror / Atom feed

From: Heikki Linnakangas <[email protected]>
To: Ayush Tiwari <[email protected]>
To: [email protected]
Subject: Re: Proposal: Prevent Primary/Standby SLRU divergence during MultiXact truncation
Date: Tue, 17 Mar 2026 00:10:41 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAJTYsWXd4s0eYnN+80ND1t1q6gabk2dbN-w-K6AJj44nz+Xd9Q@mail.gmail.com>
References: <CAJTYsWXd4s0eYnN+80ND1t1q6gabk2dbN-w-K6AJj44nz+Xd9Q@mail.gmail.com>

On 16/03/2026 18:09, Ayush Tiwari wrote:
> 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.

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.

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

Have you been able to reproduce that?

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

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.

P.S. Thanks for looking into this! This is hairy stuff, more review is 
much appreciated.

- Heikki

view thread (4+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Proposal: Prevent Primary/Standby SLRU divergence during MultiXact truncation
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox