Re: Race between prepared transaction commit and checkpointer

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, <m(dot)melnikov(at)postgrespro(dot)ru>
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(at)entry=6)
> at ./nptl/pthread_kill.c:89
> #3 0x00007de7ef24527e in __GI_raise (sig=sig(at)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
>