Re: Client failure allows backed to continue

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Client failure allows backed to continue
Дата
Msg-id 10497.1043727456@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Client failure allows backed to continue  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: Client failure allows backed to continue  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Christopher Kings-Lynne"
Дата:
Сообщение: SET NULL on NOT NULL field
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Client failure allows backed to continue