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@entry=0xb31bc8 "mode == RBM_NORMAL || mode == > RBM_ZERO_ON_ERROR || mode == RBM_ZERO_AND_LOCK", > fileName=fileName@entry=0xb31c15 "bufmgr.c", > lineNumber=lineNumber@entry=892) at assert.c:66 > #3 0x0000000000842d73 in ExtendBufferedRelTo (eb=..., > fork=fork@entry=MAIN_FORKNUM, strategy=strategy@entry=0x0, > flags=flags@entry=3, extend_to=extend_to@entry=1, > mode=mode@entry=RBM_ZERO_AND_CLEANUP_LOCK) at bufmgr.c:891 > #4 0x00000000005cc398 in XLogReadBufferExtended (rlocator=..., > forknum=MAIN_FORKNUM, blkno=0, mode=mode@entry=RBM_ZERO_AND_CLEANUP_LOCK, > recent_buffer=<optimized out>) at xlogutils.c:527 > #5 0x00000000005cc697 in XLogReadBufferForRedoExtended ( > record=record@entry=0x1183b98, block_id=block_id@entry=0 '\000', > mode=mode@entry=RBM_NORMAL, get_cleanup_lock=get_cleanup_lock@entry=true, > buf=buf@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
