On 2026-Jan-22, Álvaro Herrera wrote: > On 2026-Jan-22, Antonin Houska wrote:
> > > Do you mean replace > > > > if (unlikely(!TransactionIdDidCommit(builder->committed.xip[i]))) > > > to > > > > if (unlikely(TransactionIdIsInProgress(builder->committed.xip[i]) || > > > > !TransactionIdDidCommit(builder->committed.xip[i]))) > > > > This way the synchronous replication gets stuck, as it did when I tried to > > use > > XactLockTableWait(): subscriber cannot confirm replication of certain LSN > > because publisher is not able to even finalize the commit (due to the > > waiting > > for the subscriber's confirmation), and therefore publisher it's not able to > > decode the data and send it to the subscriber. BTW, the reason XactLockTableWait and TransactionIdIsInProgress() cause a deadlock in the same way, is that they are using essentially the same mechanism. The former uses the Lock object on the transaction, which is released (by the ResourceOwnerRelease(RESOURCE_RELEASE_LOCKS) call in CommitTransaction) after RecordTransactionCommit() has returned -- that is, after the wait on a synchronous replica has happened. XactLockTableWait does an _additional_ test for TransactionIdIsInProgress, but that should be pretty much innocuous at that point. One thing that I just realized I don't know, is what exactly are the two pieces that are deadlocking. I mean, one is this side that's decoding commit. But how/why is that other side, the one trying to mark the transaction as committed, waiting on the commit decoding? Maybe there's something that we need to do to _that_ side to prevent the blockage, so that we can use TransactionIdIsInProgress() here. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
