Listen / Notify - what to do when the queue is full
in [PgSql]
|
From: Joachim Wieland on 20 Jan 2010 03:25 On Wed, Jan 20, 2010 at 1:05 AM, Tom Lane <tgl(a)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(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 20 Jan 2010 11:14 Joachim Wieland <joe(a)mcknight.de> writes: > On Wed, Jan 20, 2010 at 1:05 AM, Tom Lane <tgl(a)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. > 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. In that case I think you've way overcomplicated matters. Just deliver the notification. We don't really care if the listener gets additional notifications; the only really bad case would be if it failed to get an event that was generated after it committed a LISTEN. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Joachim Wieland on 20 Jan 2010 15:44 On Wed, Jan 20, 2010 at 5:14 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > In that case I think you've way overcomplicated matters. Just deliver > the notification. We don't really care if the listener gets additional > notifications; the only really bad case would be if it failed to get an > event that was generated after it committed a LISTEN. Okay, what about unprocessed notifications in the queue and a backend executing UNLISTEN: can we assume that it is not interested in notifications anymore once it executes UNLISTEN and discard all of them even though there might be notifications that have been sent (and committed) before the UNLISTEN committed? Joachim -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 20 Jan 2010 15:54 Joachim Wieland <joe(a)mcknight.de> writes: > Okay, what about unprocessed notifications in the queue and a backend > executing UNLISTEN: can we assume that it is not interested in > notifications anymore once it executes UNLISTEN and discard all of > them even though there might be notifications that have been sent (and > committed) before the UNLISTEN committed? Yes. That is the case with the existing implementation as well, no? We don't consider sending notifies until transaction end, so anything that commits during the xact in which you UNLISTEN will get dropped. Again, a little bit of sloppiness here doesn't seem important. Issuing UNLISTEN implies the client is not interested anymore. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Jeff Davis on 20 Jan 2010 17:08
On Wed, 2010-01-20 at 15:54 -0500, Tom Lane wrote: > Joachim Wieland <joe(a)mcknight.de> writes: > > Okay, what about unprocessed notifications in the queue and a backend > > executing UNLISTEN: can we assume that it is not interested in > > notifications anymore once it executes UNLISTEN and discard all of > > them even though there might be notifications that have been sent (and > > committed) before the UNLISTEN committed? > > Yes. That is the case with the existing implementation as well, no? > We don't consider sending notifies until transaction end, so anything > that commits during the xact in which you UNLISTEN will get dropped. Only if the transaction containing UNLISTEN commits. Are you saying it would also be OK to drop NOTIFYs if a backend's UNLISTEN transaction aborts? > Again, a little bit of sloppiness here doesn't seem important. Issuing > UNLISTEN implies the client is not interested anymore. Thinking out loud: If we're taking this approach, I wonder if it might be a good idea to PreventTransactionChain for LISTEN and UNLISTEN? It might simplify things for users because they wouldn't be expecting transaction-like behavior, except for the NOTIFYs themselves. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |