| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Joachim Wieland <joe(at)mcknight(dot)de> |
| Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Listen / Notify - what to do when the queue is full |
| Date: | 2010-01-20 20:54:40 |
| Message-ID: | 19847.1264020880@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Joachim Wieland <joe(at)mcknight(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2010-01-20 21:17:42 | Re: per-user pg_service.conf |
| Previous Message | Josh Berkus | 2010-01-20 20:47:14 | Re: Streaming Replication and archiving |