On Wed, 2010-01-20 at 15:54 -0500, Tom Lane wrote:
> Joachim Wieland <j...@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@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
