Re: Slightly better testing for pg_ctl(1)'s -w...

Поиск
Список
Период
Сортировка
От Sean Chittenden
Тема Re: Slightly better testing for pg_ctl(1)'s -w...
Дата
Msg-id 4F9079CA-1BB5-11D9-BCB2-000A95C705DC@speakeasy.net
обсуждение исходный текст
Ответ на Re: Slightly better testing for pg_ctl(1)'s -w...  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Slightly better testing for pg_ctl(1)'s -w...  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-patches
>> pg_ctl(1)'s -w option works well if the default user can automatically
>> authenticate without any user intervention.  The attached patch checks
>> the error message to see if it's asking for a password.  The theory
>> being that if it's asking for a password, the backend is up.  I'm not
>> entirely happy with the fact that I'm dependent on the error message
>> text, but I couldn't easily figure out a better way to test this via
>> libpq(3), so I'm not too unhappy... it's just not elegant.
>
> psql and pg_dump test for this same error string, so you're in good
> company on that front, but password prompting is not the only or even
> the most likely misleading failure.  I believe both the Red Hat and
> Debian distributions set the default auth method to IDENT, meaning that
> the message you'd likely get is going to be a bleat about IDENT auth
> failing, not a password request.  Unfortunately that message is going
> to
> be localized, but it should have a SQLSTATE assigned, so you could
> check for ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION ...

Ok, I've read over the code a little bit... it doesn't seem like
there's an obvious way to get the error code via libpq(3).
CopyErrorData() looks promising, but I'm running out of time to find a
better way to do this.  Were you hinting at extending libpq(3) to
having the backend send the errcode to the frontend?  -sc

--
Sean Chittenden


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

Предыдущее
От: Sean Chittenden
Дата:
Сообщение: Re: Casting INT4 to BOOL...
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: plperl features