Re: BUG #19897: Recovery fails after "LOG: consistent recovery state reached"

Hi,

Thanks for the report and the analysis. I can reproduce this on master.

On Fri, Nov 13, 2026 at 2:27 PM PG Bug reporting form <
noreply(at)postgresql(dot)org> wrote:

>
> diff --git a/src/backend/access/transam/xlogrecovery.c
> b/src/backend/access/transam/xlogrecovery.c
> index 52ac6d58423..796226efad4 100644
> --- a/src/backend/access/transam/xlogrecovery.c
> +++ b/src/backend/access/transam/xlogrecovery.c
> @@ -2789,6 +2789,20 @@ recoveryStopsAfter(XLogReaderState *record)
> return true;
> }
>
> + /* Check if we should stop as soon as reaching consistency */
> + if (recoveryTarget == RECOVERY_TARGET_IMMEDIATE &&
> reachedConsistency)
> + {
> + ereport(LOG,
> + (errmsg("recovery stopping after reaching
> consistency")));
> +
> + recoveryStopAfter = true;
> + recoveryStopXid = InvalidTransactionId;
> + recoveryStopTime = 0;
> + recoveryStopLSN = InvalidXLogRecPtr;
> + recoveryStopName[0] = '\0';
> + return true;
> + }
> +
> if (rmid != RM_XACT_ID)
> return false;
>
> @@ -2867,20 +2881,6 @@ recoveryStopsAfter(XLogReaderState *record)
> }
> }
>
> - /* Check if we should stop as soon as reaching consistency */
> - if (recoveryTarget == RECOVERY_TARGET_IMMEDIATE &&
> reachedConsistency)
> - {
> - ereport(LOG,
> - (errmsg("recovery stopping after reaching
> consistency")));
> -
> - recoveryStopAfter = true;
> - recoveryStopXid = InvalidTransactionId;
> - recoveryStopTime = 0;
> - recoveryStopLSN = InvalidXLogRecPtr;
> - recoveryStopName[0] = '\0';
> - return true;
> - }
> -
> return false;
> }
>

Your proposed fix of moving the check above the rmgr test does fix the
reported case. But if the record that makes us consistent is a commit
or abort, it now returns before the SetLatestXTime() call, so the "last
completed transaction" time and pg_last_xact_replay_timestamp() would
miss that transaction. The attached 0001 instead goes back to the
pre-4f1b890b137 structure: the rmgr test becomes part of the condition
for the transaction-record block, so the SetLatestXTime still happens and
the immediate check is reached for every record. If this patch makes sense
i will write a TAP test, thoughts?

--
Thanks :)
Srinath Reddy Sadipiralla
EDB: https://www.enterprisedb.com/