Bruce Momjian <pgman@candle.pha.pa.us> 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 [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly