Hi Maskim, Sure I'll look into it. I'll reproduce the bug in my machine amd I'll review the patches attached in this email.
I'll let you know once I reproduce the issue in my machine and review the patch. With regards, Osama Abdul Qader On Thu, 10 Sept, 2026, 10:20 pm Maksim.Melnikov, <[email protected]> wrote: > Hi, hackers! > > I think I found an issue in two-phase commit code, I've attached patch > with reproducing, pls take a look(master rev 9f4bd91a196). > I've got coredump with backtrace like this > > #0 __pthread_kill_implementation (no_tid=0, signo=6, > threadid=<optimized out>) at ./nptl/pthread_kill.c:44 > #1 __pthread_kill_internal (signo=6, threadid=<optimized out>) at > ./nptl/pthread_kill.c:78 > #2 __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=6) > at ./nptl/pthread_kill.c:89 > #3 0x00007de7ef24527e in __GI_raise (sig=sig@entry=6) at > ../sysdeps/posix/raise.c:26 > #4 0x00007de7ef2288ff in __GI_abort () at ./stdlib/abort.c:79 > #5 0x0000610d848485bb in ExceptionalCondition > (conditionName=0x610d84910812 "XLogRecPtrIsValid(RecPtr)", > fileName=0x610d849107c2 "xlogreader.c", lineNumber=240) at assert.c:65 > #6 0x0000610d840b0926 in XLogBeginRead (state=0x610d948b06a8, RecPtr=0) > at xlogreader.c:240 > #7 0x0000610d8408ba9a in XlogReadTwoPhaseData (lsn=0, > buf=0x7fff8c941248, len=0x0) at twophase.c:1437 > #8 0x0000610d8408be05 in FinishPreparedTransaction (gid=0x610d947e6698 > "test_transaction", isCommit=true) at twophase.c:1544 > #9 0x0000610d8462b70e in standard_ProcessUtility (pstmt=0x610d947e6798, > queryString=0x610d947e5cb0 "COMMIT PREPARED 'test_transaction';", > readOnlyTree=false, > context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, > dest=0x610d947e6b58, qc=0x7fff8c941730) at utility.c:655 > #10 0x0000610d8462ade6 in ProcessUtility (pstmt=0x610d947e6798, > queryString=0x610d947e5cb0 "COMMIT PREPARED 'test_transaction';", > readOnlyTree=false, > context=PROCESS_UTILITY_TOPLEVEL, params=0x0, queryEnv=0x0, > dest=0x610d947e6b58, qc=0x7fff8c941730) at utility.c:525 > #11 0x0000610d846293ee in PortalRunUtility (portal=0x610d94864a20, > pstmt=0x610d947e6798, isTopLevel=true, setHoldSnapshot=false, > dest=0x610d947e6b58, qc=0x7fff8c941730) > at pquery.c:1149 > #12 0x0000610d84629668 in PortalRunMulti (portal=0x610d94864a20, > isTopLevel=true, setHoldSnapshot=false, dest=0x610d947e6b58, > altdest=0x610d947e6b58, qc=0x7fff8c941730) > at pquery.c:1307 > #13 0x0000610d84628ac0 in PortalRun (portal=0x610d94864a20, > count=9223372036854775807, isTopLevel=true, dest=0x610d947e6b58, > altdest=0x610d947e6b58, qc=0x7fff8c941730) at pquery.c:784 > #14 0x0000610d84620b10 in exec_simple_query (query_string=0x610d947e5cb0 > "COMMIT PREPARED 'test_transaction';") at postgres.c:1297 > .... > > > It seems we have race between prepared transaction commit and > checkpointer and it is old problem. We need TwoPhaseStateLock wrap the > reading state file in FinishPreparedTransaction code, the draft patch is > attached too, hope it will be helpful. > > > Best regards, > Maksim Melnikov >
