Bernd Helmle wrote:
> While investigating a problem on a streaming hot standby instance at a
> customer site, i got the following when using a standalone backend:
> PANIC:  btree_xlog_delete_get_latestRemovedXid: cannot operate with
> inconsistent data
> CONTEXT:  xlog redo delete: index 1663/65588/65625; iblk 11, heap
> 1663/65588/65613;
> The responsible PANIC is triggered here:
> src/backend/access/nbtree/nbtxlog.c:555
> btree_xlog_delete_get_latestRemovedXid(XLogReaderState *record)

This PANIC was introduced in the commit below.  AFAICS your proposed
patch and rationale are correct.

commit f786e91a75b2f64527dcf321e754b6448fcad7fe
Author:     Tom Lane <>
AuthorDate: Fri Aug 3 15:41:18 2012 -0400
CommitDate: Fri Aug 3 15:41:18 2012 -0400

    Improve underdocumented btree_xlog_delete_get_latestRemovedXid() code.
    As noted by Noah Misch, btree_xlog_delete_get_latestRemovedXid is
    critically dependent on the assumption that it's examining a consistent
    state of the database.  This was undocumented though, so the
    seemingly-unrelated check for no active HS sessions might be thought to be
    merely an optional optimization.  Improve comments, and add an explicit
    check of reachedConsistency just to be sure.
    This function returns InvalidTransactionId (thereby killing all HS
    transactions) in several cases that are not nearly unlikely enough for my
    taste.  This commit doesn't attempt to fix those deficiencies, just
    document them.
    Back-patch to 9.2, not from any real functional need but just to keep the
    branches more closely synced to simplify possible future back-patching.

Álvaro Herrera      
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to