On 03.12.2011 18:37, Heikki Linnakangas wrote:
> One small change I'd like to make is to treat the loss of connection
> more as a new "top-level" event, rather than as a new reason for query
> cancellation. A lost connection is more like receiving SIGTERM, really.
> Please take a look at the attached patch. I've been testing this by
> doing "SELECT pg_sleep(1), a from generate_series(1,1000) a;", and
> killing the connection with "killall -9 psql".
Ok, committed this.
> One remaining issue I have with this is the wording of the error
> message. The closest existing message we have is in old-mode COPY:
>
> ereport(FATAL,
> (errcode(ERRCODE_CONNECTION_FAILURE),
> errmsg("connection lost during COPY to stdout")));
>
> In the patch, I made the new message just "connection lost", but does
> anyone else have a better opinion on that? Perhaps it should be
> "connection lost while sending response to client". Or "connection lost
> during execution of statement", but that might not be accurate if we're
> not executing a statement at the moment, but just sending a "sync"
> message or similar.
I made the error message "connection to client lost" in the end.
I still wonder if it would be safe to simply elog(FATAL) in
internal_flush(), but didn't dare to do that without more thorough analysis.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
