Re: Network write errors (was: Re: Feature freeze date for
От | Bruce Momjian |
---|---|
Тема | Re: Network write errors (was: Re: Feature freeze date for |
Дата | |
Msg-id | 200505260127.j4Q1RNj06476@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Network write errors (was: Re: Feature freeze date for 8.1) (Andrew - Supernews <andrew+nonews@supernews.com>) |
Ответы |
Re: Network write errors (was: Re: Feature freeze date for
|
Список | pgsql-hackers |
Andrew - Supernews wrote: > On 2005-05-01, Peter Eisentraut <peter_e@gmx.net> wrote: > > The problem, as I understand it, is that if you have a long-running > > query and the client process disappears, the query keeps running and > > holds whatever resources it may have until it finishes. In fact, it > > keeps sending data to the client and keeps ignoring the SIGPIPE it gets > > (in case of a Unix-domain socket connection). > > Ignoring the SIGPIPE is exactly the right thing to do. > > What's _not_ a good idea is ignoring the EPIPE error from write(), which > seems to currently be reported via ereport(COMMERROR) which doesn't try > and abort the query as far as I can tell. Where are you seeing this? I looked from PostgresMain() to ReadCommand() to SocketBackend() to pq_getbyte() which returns EOF, and PostgresMain checks that and does a proc_exit(0). I think the main problem is that a long-running query never tries to interact with the client during the query. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
В списке pgsql-hackers по дате отправления: