Re: Listen / Notify - what to do when the queue is full - Mailing list pgsql-hackers

From Joachim Wieland
Subject Re: Listen / Notify - what to do when the queue is full
Date
Msg-id dc7b844e0911181559w5801cd9cr7830e181a1a7c191@mail.gmail.com
Whole thread Raw
In response to Listen / Notify - what to do when the queue is full  (Joachim Wieland <joe@mcknight.de>)
Responses Re: Listen / Notify - what to do when the queue is full
List pgsql-hackers
On Sun, Nov 15, 2009 at 7:19 PM, Joachim Wieland <joe@mcknight.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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Amazing performance failure with SQL function
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Python 3.1 support