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...
|
Список | 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 по дате отправления: