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 <[EMAIL PROTECTED]> 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
  [EMAIL PROTECTED]               |  (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 via email to