| От | Andrew Chernow |
|---|---|
| Тема | Re: Listen / Notify - what to do when the queue is full |
| Дата | |
| Msg-id | 4B04A8AB.5080508@esilo.com обсуждение исходный текст |
| Ответ на | Re: Listen / Notify - what to do when the queue is full (Josh Berkus <josh@agliodbs.com>) |
| Ответы |
Re: Listen / Notify - what to do when the queue is full
|
| Список | pgsql-hackers |
> We should probably also log the fact that we ran out of room, so that > the DBA knows that they ahve a design issue. Can't they just bump allowed memory and avoid a redesign? > Alternately, it would be great to have a configuration option which > would allow the DBA to choose any of 3 behaviors via GUC: > > drop-oldest (as above) > drop-largest (if we run out of room, drop the largest payloads first to > save space) > error (if we run out of room, error and rollback) > I mentioned this up thread. I completely agree that overflow behavior should be tunable. -- Andrew Chernow eSilo, LLC every bit counts http://www.esilo.com/
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера