Re: Listen / Notify - what to do when the queue is full

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

In response to

Responses

Browse pgsql-hackers by date

  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