Re: Client failure allows backed to continue

Well, setting query_cancel then seems like a logical solution because it
will exit at a reasonable point, hopefully.  Right now we have
statement_timeout and that exits at a give time, but I suppose it
doesn't exit while data is transfering, so it may be different.

---------------------------------------------------------------------------

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Well, if we get an I/O error, I can't imagine why we would continue
> > doing anything --- are any of those recoverable?
> 
> Well, that's what's not clear --- it's hard to tell if a write failure
> is a hard error or just transient.  If we make like elog(ERROR),
> returning to the main loop, and then a read from the client *doesn't*
> fail, we'll try to continue ... but we've just screwed the pooch,
> because we have not sent a complete message and therefore certainly have
> messed up frontend/backend synchronization.  I have no idea whether it's
> really possible to recover from this situation or not, but that approach
> surely won't work.
> 
> If you want to take a kamikaze any-comm-error-means-we're-dead approach,
> you might think about elog(FATAL).  But that tries to send a message to
> the client.  Instant infinite loop, if the error is hard.
> 
> Complaints to the postmaster log, and abort at the next safe place
> (*not* partway through message output) seem like the way to go to me.
> 
> > Do we need a separate error type for I/O messages?
> 
> Uh ... see COMMERROR.
> 
>             regards, tom lane
> 

--  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