From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Joachim Wieland <joe(at)mcknight(dot)de> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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: | 2009-11-20 11:34:08 |
Message-ID: | 4B067EB0.1030701@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Joachim Wieland wrote:
> On Thu, Nov 19, 2009 at 11:04 PM, Joachim Wieland <joe(at)mcknight(dot)de> wrote:
>> Given your example, what I am proposing now is to stop reading from
>> the queue once we see a not-yet-committed notification but once the
>> queue is full, read the uncommitted notifications, effectively copying
>> them over into the backend's own memory... Once the transaction
>> commits and sends a signal, we can process, send and discard the
>> previously copied notifications. In the above example, at some point
>> one, two or all three backends would see that the queue is full and
>> everybody would read the uncommitted notifications of the other one,
>> copy them into the own memory and space will be freed in the queue.
>
> Attached is the patch that implements the described modifications.
That's still not enough if session 2 that issues the LISTEN wasn't
previously subscribed to any channels. It will still miss the notification.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2009-11-20 13:35:49 | Re: enable-thread-safety defaults? |
Previous Message | Heikki Linnakangas | 2009-11-20 09:48:44 | Re: Listen / Notify - what to do when the queue is full |