From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Assertion being hit during WAL replay |
Date: | 2023-04-11 18:48:44 |
Message-ID: | 392271.1681238924@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I have seen this failure a couple of times recently while
testing code that caused crashes and restarts:
#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.
In any case, I'm pretty sure Andres broke it in 26158b852, because
I hadn't seen it before this weekend.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2023-04-11 18:49:55 | Re: When to drop src/tools/msvc support |
Previous Message | Sandro Santilli | 2023-04-11 18:48:23 | Re: [PATCH] Support % wildcard in extension upgrade filenames |