Re: Client failure allows backed to continue - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Client failure allows backed to continue
Date
Msg-id 10497.1043727456@sss.pgh.pa.us
Whole thread Raw
In response to Re: Client failure allows backed to continue  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: Client failure allows backed to continue  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: "Christopher Kings-Lynne"
Date:
Subject: SET NULL on NOT NULL field
Next
From: Bruce Momjian
Date:
Subject: Re: Client failure allows backed to continue