Dear Antonin, FYI, I have also been spending time to reproduce the failure but I have not done yet.
> So far I could observe the situation in WAL, but have no idea how it can > happen. Not sure it matches with your situation, but I could reproduce the situation by using gdb. 0. initialized an instance with wal_level=logical and defined a table. 1. established a connection 2. attached the backend via gdb 3. added a breakpoint in ProcArrayEndTransaction 4. committed a transaction, and it would stop at the breakpoint 5. established another connection 6. ran REPACK CONCURRENTLY 7. detached from the first backend. 8. all commands would finish. This could allow that COMMIT record exists ahead the RUNNING_XACTS record. When the backend reaches CommitTransaction()->ProcArrayEndTransaction(), the commit record has already been serialized, but the transaction is still marked as active on the proc array. Above workload allowed that repack worker could check in-between. [1]: ``` rmgr: Transaction len (rec/tot): 46/ 46, tx: 695, lsn: 0/018B89C0, prev 0/018B8980, desc: COMMIT 2026-05-12 11:11:31.588061 JST rmgr: Standby len (rec/tot): 58/ 58, tx: 0, lsn: 0/018B89F0, prev 0/018B89C0, desc: RUNNING_XACTS nextXid 696 latestCompletedXid 694 oldestRunningXid 695; 1 xacts: 695; dbid: 0 rmgr: Standby len (rec/tot): 58/ 58, tx: 0, lsn: 0/018B8A30, prev 0/018B89F0, desc: RUNNING_XACTS nextXid 696 latestCompletedXid 694 oldestRunningXid 695; 1 xacts: 695; dbid: 5 ``` Best regards, Hayato Kuroda FUJITSU LIMITED
