On Wed, Sep 3, 2025 at 2:14 PM Matheus Alcantara <[email protected]> wrote:
> IIUC we don't store notifications of aborted transactions on the > queue. On PreCommit_Notify we add the notifications on the queue > and on Commit_Notify() we signal the backends. > > Or I'm missing something here? My understanding is that something could go wrong in between PreCommit_Notify and AtCommit_Notify, which could cause the transaction to abort, and the notification might be in the queue at this point, even though the transaction aborted, hence the dependency on the commit log. > Maybe we could have a boolean "committed" field on AsyncQueueEntry > and check this field before sending the notification instead of > call TransactionIdDidCommit()? Is something similar what you are > proposing? I like this direction, as it opens up the ability to remove the global lock held from PreCommit_Notify to the end of the transaction. In the same vein as this idea, I was experimenting with a patch inspired by Tom Lane’s idea in [1] where we write the actual notification data into the WAL, and just write the db, lsn, and xid into the notify queue in AtCommit_Notify, so the notify queue only contains information about committed transactions. Unfortunately, the additional WAL write overhead in this approach seemed to outweigh the benefits of removing the lock. Following that idea - I think perhaps we could have two queues in the notify system, one that stores the notification data, and another that stores the position of the committed transaction’s notification, which we would append to in AtCommit_Notify. Then the listener would go through the position queue, and find / read the notifications from the notify data queue. [1] https://www.postgresql.org/message-id/1878165.1752858390%40sss.pgh.pa.us
