Re: Bug in walsender when calling out to do_pg_stop_backup (and others?)

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