Re: Listen / Notify - what to do when the queue is full
От | Joachim Wieland |
---|---|
Тема | Re: Listen / Notify - what to do when the queue is full |
Дата | |
Msg-id | dc7b844e0911181559w5801cd9cr7830e181a1a7c191@mail.gmail.com обсуждение исходный текст |
Ответ на | Listen / Notify - what to do when the queue is full (Joachim Wieland <joe@mcknight.de>) |
Ответы |
Re: Listen / Notify - what to do when the queue is full
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: