From: | Joachim Wieland <joe(at)mcknight(dot)de> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Listen / Notify - what to do when the queue is full |
Date: | 2009-11-18 23:59:42 |
Message-ID: | dc7b844e0911181559w5801cd9cr7830e181a1a7c191@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Nov 15, 2009 at 7:19 PM, Joachim Wieland <joe(at)mcknight(dot)de> wrote:
> These are the solutions that I currently see:
> 1) [...]
> 2) [...]
> 3) [...]
4) Allow readers to read uncommitted notifications as well. Instead of
delivering them, the backends just copy them over into their own
address space and deliver them later on...
Going with option 4) allows readers to always read all notifications
in the queue... This also allows a backend to send more notifications
than the queue can hold. So we are only limited by the backends'
memory. Every notification that is sent will eventually be delivered.
The queue can still fill up if one of the backends is busy for a long
long long time... Then the next writer just blocks and waits.
Attached patch implements this behavior as well as a variable payload
size, limited to 8000 characters. The variable payload also offers an
automatic speed control... The smaller your notifications are, the
more efficiently a page can be used and the faster you are. :-)
Once we are fine that this is the way to go, I'll submit a documentation patch.
Joachim
Attachment | Content-Type | Size |
---|---|---|
listennotify.2.diff | text/x-diff | 65.4 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-11-19 00:48:17 | Re: Listen / Notify - what to do when the queue is full |
Previous Message | Tom Lane | 2009-11-18 22:43:48 | Re: Amazing performance failure with SQL function |