Re: fix special case during recovery for hot_standby=off

From: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: fix special case during recovery for hot_standby=off
Date: 2026-11-11 10:56:29
Message-ID: CAJTYsWUdAuktjcCKE=o6SSZaxxLjWQWnkz3+qGpSN2B2LH6ZTA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Sat, 7 Nov 2026 at 04:48, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>
> In xact_redo_commit(), the standbyState != STANDBY_DISABLED case uses
> TransactionIdAsyncCommitTree() on the grounds that we can't let hint
> bits be set for transactions prior to minRecoveryPoint. Based on that
> reasoning, the STANDBY_DISABLED case doesn't need to worry, because it
> won't be setting hint bits.
>
> But hint bits aren't the only problem: we also can't let the CLOG
> status go to disk prior to minRecoveryPoint, because a PITR to just
> before the transaction committed could still see it as committed.

Thanks for the report. I tried this on master and could still see the
row after promotion, even though recovery stopped before the commit.
With your patch, recovery rejects that target instead with "requested
recovery stop point is before consistent recovery point".

This was with hot_standby=off, reusing the standby's data directory
after a crash. I used a lot of subxacts to get the CLOG page evicted
during replay.

> The cleanest fix would be to lift TransactionIdAsyncCommitTree() out of
> the branch, placing it prior to RecordKnownAssignedTransactionIds() on
> the !STANDBY_DISABLED case. But the comment above
> RecordKnownAssignedTransactionIds() is especially scary, so out of an
> abundance of caution I just replaced the call site for the
> STANDBY_DISABLED case. That seems wise for the back branches, and we
> can get rid of the second call site in master in a separate commit.

Yeah makes sense to me for using this for back branches and leaving the
clean up for master.

> Patch attached.

Looks good to me.

Regards,
Ayush

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Jones 2026-11-11 11:06:56 XML functions can exhaust backend memory with libxml2 < 2.11
Previous Message Chao Li 2026-11-11 10:51:47 Re: Fix resource leaks in pg_receivewal on LZ4 close failures