| 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: | Whole Thread | Raw Message | 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 |