Re: standalone backend PANICs during recovery

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