Re: Re: [BUGS] BUG #5650: Postgres service showing as stopped when in fact it is running

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Re: [BUGS] BUG #5650: Postgres service showing as stopped when in fact it is running
Дата
Msg-id 5594.1290814203@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Re: [BUGS] BUG #5650: Postgres service showing as stopped when in fact it is running  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Re: [BUGS] BUG #5650: Postgres service showing as stopped when in fact it is running  (Robert Haas <robertmhaas@gmail.com>)
Re: Re: [BUGS] BUG #5650: Postgres service showing as stopped when in fact it is running  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
I wrote:
> The reason this is a problem is that somebody, in a fit of inappropriate
> optimization, took out the code that allowed canAcceptConnections to
> distinguish the "not consistent yet" state.

Oh, no, that's not the case --- the PM_RECOVERY postmaster state does
still distinguish not-ready from ready.  The real problem is that what
Bruce implemented has practically nothing to do with what was discussed
last week.  PQping is supposed to be smarter about classifying errors
than this.

Speaking of classifying errors, should we have a fourth result value to
cover "obviously bogus parameters"?  Right now you'll get PQNORESPONSE
for cases like incorrect syntax in the conninfo string.  I'm not sure
how tense we ought to try to be about distinguishing, but if libpq
failed before even attempting a connection, PQNORESPONSE seems a bit
misleading.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: duplicate connection failure messages
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Assertion failure on hot standby