Re: BUG #12788: host / peer auth works after pg_ctl reload, then blocks server startup
От | Tom Lane |
---|---|
Тема | Re: BUG #12788: host / peer auth works after pg_ctl reload, then blocks server startup |
Дата | |
Msg-id | 19897.1424394086@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #12788: host / peer auth works after pg_ctl reload, then blocks server startup (dannyman@toldme.com) |
Список | pgsql-bugs |
dannyman@toldme.com writes: > I naively added a line like this to pg_hba.conf: > host all postgres x.x.x.x/32 peer > I ran pg_ctl reload. "pg_ctl reload" unfortunately has no way to detect whether the reload succeeded. Had you checked in the postmaster log you'd likely have found some bleating to the effect that the reload didn't take. > I was then able to connect from x.x.x.x to do backups. If so, it must have been due to some previously existing entry. > I then restarted the server, and it failed, with this error: > LOG: peer authentication is only supported on local sockets Yup ... > I can see why pg_ctl reload might gloss over a config issue instead of > bringing down the server, but that the invalid auth configuration then works > strokes me as a bug. It didn't "work". Making the postmaster keep running despite the attempt to load a bad file has been generally agreed to be the best thing, but it does mean that if you don't pay attention to the effects of a reload, you can shoot yourself in the foot like this :-(. AFAICS the only thing we could do to make this significantly safer would be to restrict use of "pg_ctl reload" to scenarios wherein pg_ctl could determine whether the postmaster had reloaded its config without any complaints. Unfortunately, that would be a pretty draconian restriction, so there's no free lunch here. regards, tom lane
В списке pgsql-bugs по дате отправления: