Re: Listen / Notify - what to do when the queue is full
Вложения
В списке pgsql-hackers по дате отправления:
| От | Joachim Wieland |
|---|---|
| Тема | Re: Listen / Notify - what to do when the queue is full |
| Дата | |
| Msg-id | dc7b844e0911200135j1d01f896u38269d00a10bd342@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: 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
Re: Listen / Notify - what to do when the queue is full |
| Список | pgsql-hackers |
On Thu, Nov 19, 2009 at 11:04 PM, Joachim Wieland <joe@mcknight.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
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера