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 <tgl@sss.pgh.pa.us>
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_latestRemovedXidis critically dependent on the assumption that it's examining a consistent
stateof the database. This was undocumented though, so the seemingly-unrelated check for no active HS sessions might
bethought to be merely an optional optimization. Improve comments, and add an explicit check of reachedConsistency
justto be sure. This function returns InvalidTransactionId (thereby killing all HS transactions) in several
casesthat are not nearly unlikely enough for my taste. This commit doesn't attempt to fix those deficiencies, just
documentthem. Back-patch to 9.2, not from any real functional need but just to keep the branches more closely
syncedto simplify possible future back-patching.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services