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
