Re: [HACKERS] Network write errors (was: Re: Feature freeze date for

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [HACKERS] Network write errors (was: Re: Feature freeze date for

Bruce Momjian-2
Andrew - Supernews wrote:

> On 2005-05-01, Peter Eisentraut <[hidden email]> 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
  [hidden email]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster
Reply | Threaded
Open this post in threaded view
|

Re: [HACKERS] Network write errors (was: Re: Feature freeze date for

Tom Lane-2
Bruce Momjian <[hidden email]> writes:
> Andrew - Supernews wrote:
>> 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).

It sounds like you were following the input-from-client logic.  Andrew
is complaining about the output-to-client side.

We deliberately don't abort on write-to-client failure.  There have
been periodic discussions about changing that, but I'm not convinced
that the advocates for a change have made a good case.  Right now,
it's predictable that the backend only fails due to loss of connection
when it waits for a new command.  The behavior would become much less
predictable if we allowed write failure to abort the query.  As an
example: whether an UPDATE command completes might depend on whether
any invoked triggers try to issue NOTICEs.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
      subscribe-nomail command to [hidden email] so that your
      message can get through to the mailing list cleanly