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 | 14128.1143471038@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Followup comment for bug report 'postmaster ignores SIGPIPE' [was: Bug#255208: Would help with client aborts, too.] ("Jim C. Nasby" <jnasby@pervasive.com>) |
| Ответы |
Re: Followup comment for bug report 'postmaster ignores SIGPIPE' [was: Bug#255208: Would help with client aborts, too.]
|
| Список | pgsql-bugs |
"Jim C. Nasby" <jnasby@pervasive.com> writes:
> On Sun, Mar 26, 2006 at 08:34:46PM -0500, Tom Lane wrote:
>> 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.
> Is there a server equivalent to PQstatus? If there were one, couldn't
> the server periodically ping the client?
No, and do you really want the server stopping its processing of the
query just to go see if the client is still alive? This would slow
things down and introduce a whole new failure mode, ie, client doesn't
answer ping fast enough so its session gets aborted.
(Just for the record, PQstatus isn't a "ping" operation either.)
regards, tom lane
В списке pgsql-bugs по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера