[ got around to looking at this finally ]
Alvaro Herrera <alvhe...@2ndquadrant.com> writes:
> 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
> This PANIC was introduced in the commit below. AFAICS your proposed
> patch and rationale are correct.
I'm not very convinced by this. What seems to me to be the core issue is
how it can make sense for InHotStandby to read as TRUE in a standalone
backend. The best-case situation if that's true is that the standalone
backend will do a lot of unnecessary work on the baseless assumption that
there are other backends it has to keep things valid for. The worst-case
situation is that you trip over some bug and are unable to complete
recovery, even though you would have if the hot-standby support hadn't
been activated.
In short, I don't think control should have been here at all. My proposal
for a fix is to force EnableHotStandby to remain false in a standalone
backend.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
