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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Jaime Casanova
Дата:
Сообщение: Re: adding a function to pg_proc.h
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Source Code Help Needed