| From: | Joachim Wieland <joe(at)mcknight(dot)de> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| 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 09:35:46 |
| Message-ID: | dc7b844e0911200135j1d01f896u38269d00a10bd342@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
Joachim
| Attachment | Content-Type | Size |
|---|---|---|
| listennotify.3.diff | text/x-diff | 77.1 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2009-11-20 09:48:44 | Re: Listen / Notify - what to do when the queue is full |
| Previous Message | Tino Wildenhain | 2009-11-20 09:30:05 | Re: Python 3.1 support |