Re: Followup comment for bug report 'postmaster ignores SIGPIPE' [was: Bug#255208: Would help with client aborts, too.]
В списке pgsql-bugs по дате отправления:
| От | Tom Lane |
|---|---|
| Тема | Re: Followup comment for bug report 'postmaster ignores SIGPIPE' [was: Bug#255208: Would help with client aborts, too.] |
| Дата | |
| Msg-id | 29170.1143423286@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Followup comment for bug report 'postmaster ignores SIGPIPE' [was: Bug#255208: Would help with client aborts, too.] (Peter Eisentraut <peter_e@gmx.net>) |
| Ответы |
Re: Followup comment for bug report 'postmaster ignores SIGPIPE' [was: Bug#255208: Would help with client aborts, too.]
|
| Список | pgsql-bugs |
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> Allowing SIGPIPE to kill the backend is completely infeasible, as the
>> backend would be unable to release locks etc before dying.
> So the upshot is really not that ignoring SIGPIPE is specifically
> intended as the optimal solution but that writing a proper cleanup
> handler for SIGPIPE seems very difficult.
Well, if we did want to change this it would be far easier and safer to
do the other thing (ie, set QueryCancel upon noticing a write failure).
The question is whether doing either one is really a material
improvement, seeing that neither is going to provoke an abort
until/unless the backend actually tries to write something to the client.
regards, tom lane
В списке pgsql-bugs по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера