| From: | Joachim Wieland <joe(at)mcknight(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| 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:44:02 |
| Message-ID: | dc7b844e1001201244k231b7913yfef1f061a53c5549@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Jan 20, 2010 at 5:14 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2010-01-20 20:47:14 | Re: Streaming Replication and archiving |
| Previous Message | Tom Lane | 2010-01-20 20:18:26 | Re: Synchronization primitives (Was: Re: An example of bugs for Hot Standby) |