On Wed, Jan 20, 2010 at 1:05 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > I guess Joachim is trying to provide a similar guarantee for the new > implementation, but I'm not clear on why it would require locking. > The new implementation is broadcast and ISTM it shouldn't require the > modifying transaction to know which processes are listening.
It is rather about a listening backend seeing a notification in the global queue without knowing if it should deliver the notification to its frontend or not. The backend needs to know if its own LISTEN committed before or after the NOTIFY committed that it sees in the queue. As I have understood there is no way to find out if a transaction has committed before or after another transaction. If we had this, it would be easy without a lock. > I haven't read the patch but I agree that the description you give is > pretty scary from a performance standpoint. More locks around > transaction commit doesn't seem like a good idea. If they're only taken > when an actual LISTEN or NOTIFY has happened in the current transaction, > that'd be okay (certainly no worse than what happens now) but the naming > suggested that this'd happen unconditionally. The lock is taken exclusively by transactions doing LISTEN/UNLISTEN and in shared mode by transactions that execute only NOTIFY. It should really not degrade performance but I understand Jeff's concerns about deadlocks. Joachim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers