Date: Thu, 31 Mar 2016 11:27:27 +0200
From: Bernd Helmle <mailings@oopsware.de>
To: pgsql-hackers@postgresql.org
Subject: standalone backend PANICs during recovery
Message-ID: <00F0B2CEF6D0CEF8A90119D4@eje.credativ.lan>
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="==========0A4950252DB9C379855E=========="
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

--==========0A4950252DB9C379855E==========
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size=1029

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
--==========0A4950252DB9C379855E==========
Content-Type: application/octet-stream; name="standalone_recover.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="standalone_recover.patch";
 size=568

ZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL2FjY2Vzcy9uYnRyZWUvbmJ0eGxv
Zy5jIGIvc3JjL2JhY2tlbmQvYWNjZXNzL25idHJlZS9uYnR4bG9nLmMKaW5k
ZXggMmRlYmI4Ny4uMDQ4OTk2OSAxMDA2NDQKLS0tIGEvc3JjL2JhY2tlbmQv
YWNjZXNzL25idHJlZS9uYnR4bG9nLmMKKysrIGIvc3JjL2JhY2tlbmQvYWNj
ZXNzL25idHJlZS9uYnR4bG9nLmMKQEAgLTYxOCw3ICs2MTgsNyBAQCBidHJl
ZV94bG9nX2RlbGV0ZV9nZXRfbGF0ZXN0UmVtb3ZlZFhpZCh4bF9idHJlZV9k
ZWxldGUgKnhscmVjKQogCSAqIHN0YXJ0IGp1c3QgYWZ0ZXIgd2UgbG9vay4g
IElmIHNvLCBpdCBjYW5ub3QgbmVlZCB0byBjb25mbGljdCwgYnV0IHRoaXMK
IAkgKiBjb2Rpbmcgd2lsbCByZXN1bHQgaW4gdGhyb3dpbmcgYSBjb25mbGlj
dCBhbnl3YXkuCiAJICovCi0JaWYgKENvdW50REJCYWNrZW5kcyhJbnZhbGlk
T2lkKSA9PSAwKQorCWlmICgoQ291bnREQkJhY2tlbmRzKEludmFsaWRPaWQp
ID09IDApIHx8ICghSXNQb3N0bWFzdGVyRW52aXJvbm1lbnQpKQogCQlyZXR1
cm4gbGF0ZXN0UmVtb3ZlZFhpZDsKIAogCS8qCg==

--==========0A4950252DB9C379855E==========
Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


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

--==========0A4950252DB9C379855E==========--