Re: Assertion being hit during WAL replay

Hi,

On 2023-04-11 14:48:44 -0400, Tom Lane wrote:
> I have seen this failure a couple of times recently while
> testing code that caused crashes and restarts:

Do you have a quick repro recipe?

> #2 0x00000000009987e3 in ExceptionalCondition (
> conditionName=conditionName(at)entry=0xb31bc8 "mode == RBM_NORMAL || mode == RBM_ZERO_ON_ERROR || mode == RBM_ZERO_AND_LOCK",
> fileName=fileName(at)entry=0xb31c15 "bufmgr.c",
> lineNumber=lineNumber(at)entry=892) at assert.c:66
> #3 0x0000000000842d73 in ExtendBufferedRelTo (eb=...,
> fork=fork(at)entry=MAIN_FORKNUM, strategy=strategy(at)entry=0x0,
> flags=flags(at)entry=3, extend_to=extend_to(at)entry=1,
> mode=mode(at)entry=RBM_ZERO_AND_CLEANUP_LOCK) at bufmgr.c:891
> #4 0x00000000005cc398 in XLogReadBufferExtended (rlocator=...,
> forknum=MAIN_FORKNUM, blkno=0, mode=mode(at)entry=RBM_ZERO_AND_CLEANUP_LOCK,
> recent_buffer=<optimized out>) at xlogutils.c:527
> #5 0x00000000005cc697 in XLogReadBufferForRedoExtended (
> record=record(at)entry=0x1183b98, block_id=block_id(at)entry=0 '\000',
> mode=mode(at)entry=RBM_NORMAL, get_cleanup_lock=get_cleanup_lock(at)entry=true,
> buf=buf(at)entry=0x7ffd98e3ea94) at xlogutils.c:391
> #6 0x000000000055df59 in heap_xlog_prune (record=0x1183b98) at heapam.c:8779
> #7 heap2_redo (record=0x1183b98) at heapam.c:10015
> #8 0x00000000005ca430 in ApplyWalRecord (replayTLI=<synthetic pointer>,
> record=0x7f8f7afbcb60, xlogreader=<optimized out>)
> at ../../../../src/include/access/xlog_internal.h:379
>
> It's not clear to me whether this Assert is wrong, or
> XLogReadBufferForRedoExtended shouldn't be using
> RBM_ZERO_AND_CLEANUP_LOCK, or the Assert is correctly protecting an
> unimplemented case in ExtendBufferedRelTo that we now need to implement.

Hm. It's not implemented because I didn't quite see how it'd make sense to
pass RBM_ZERO_AND_CLEANUP_LOCK when extending the relation, but given how
relation extension is done "implicitly" during recovery, that's too narrow a
view. It's trivial to add.

I wonder if we should eventually redefine the RBM* things into a bitmask.

> In any case, I'm pretty sure Andres broke it in 26158b852, because
> I hadn't seen it before this weekend.

Yea, that's clearly the fault of 26158b852.

Greetings,

Andres Freund