pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Bernd Helmle <mailings@oopsware.de>
To: pgsql-hackers@postgresql.org
Subject: standalone backend PANICs during recovery
Date: Thu, 31 Mar 2016 11:27:27 +0200
Message-ID: <00F0B2CEF6D0CEF8A90119D4@eje.credativ.lan> (raw)
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>

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)
{

[...]
	if (!reachedConsistency)
		elog(PANIC, "btree_xlog_delete_get_latestRemovedXid: cannot operate with
inconsistent data");
[...]

}

There's already an "optimization" before, exiting with InvalidTransactionId
in case a HS doesn't count any active backends. In standalone mode however,
CountDBBackends() will always return 1 afaik. It looks like
btree_xlog_delete_get_latestRemovedXid() needs an additional check for
standalone backends, so i came up with the attached patch. This allowed the
standalone backend to recover without any problems.

-- 
Thanks

	Bernd

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Attachments:

standalone_recover.patch (application/octet-stream, 568B) download diff --git a/src/backend/access/nbtree/nbtxlog.c b/src/backend/access/nbtree/nbtxlog.c index 2debb87..0489969 100644 --- a/src/backend/access/nbtree/nbtxlog.c +++ b/src/backend/access/nbtree/nbtxlog.c @@ -618,7 +618,7 @@ btree_xlog_delete_get_latestRemovedXid(xl_btree_delete *xlrec) * start just after we look. If so, it cannot need to conflict, but this * coding will result in throwing a conflict anyway. */ - if (CountDBBackends(InvalidOid) == 0) + if ((CountDBBackends(InvalidOid) == 0) || (!IsPostmasterEnvironment)) return latestRemovedXid; /*

view thread (18+ messages)  latest in thread

Message-ID: <00F0B2CEF6D0CEF8A90119D4@eje.credativ.lan>
Permalink:  ../00F0B2CEF6D0CEF8A90119D4@eje.credativ.lan/
Also on:    postgresql.org/message-id/00F0B2CEF6D0CEF8A90119D4@eje.credativ.lan

 ·  · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: mailings@oopsware.de
  Subject: Re: standalone backend PANICs during recovery
  In-Reply-To: <00F0B2CEF6D0CEF8A90119D4@eje.credativ.lan>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox