Re: Race between prepared transaction commit and checkpointer

Thanks, I found one more suspicious place, pls take a look at
checkpointer  CheckPointTwoPhase method, I am little bit suprised that
we acquire LW_SHARED lock here, because with this lock

we are changing gxact members, if some concurrent proc read this one
with LW_SHARED, it can get stale values. I am not sure but for example
it can be LookupGXact.

Anyway, if I am mistaken, sorry for noise.

Best regards,

Maksim Melnikov

On 9/10/26 21:12, Osama Abdul Qader wrote:
> 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
>