From: | Bernd Helmle <mailings(at)oopsware(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | standalone backend PANICs during recovery |
Date: | 2016-03-31 09:27:27 |
Message-ID: | 00F0B2CEF6D0CEF8A90119D4@eje.credativ.lan |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-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
Attachment | Content-Type | Size |
---|---|---|
standalone_recover.patch | application/octet-stream | 568 bytes |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2016-03-31 09:37:22 | Re: Speed up Clog Access by increasing CLOG buffers |
Previous Message | Pavel Stehule | 2016-03-31 09:22:20 | Re: IF (NOT) EXISTS in psql-completion |