Re: Parsing of pg_hba.conf and authentication inconsistencies
От | Tom Lane |
---|---|
Тема | Re: Parsing of pg_hba.conf and authentication inconsistencies |
Дата | |
Msg-id | 4550.1217695740@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Parsing of pg_hba.conf and authentication inconsistencies (Alvaro Herrera <alvherre@commandprompt.com>) |
Ответы |
Re: Parsing of pg_hba.conf and authentication inconsistencies
|
Список | pgsql-hackers |
Alvaro Herrera <alvherre@commandprompt.com> writes: > Tom Lane wrote: >> Idle thought: maybe what would really make sense here is a "lint" >> for PG config files, > I like this idea. > postgres --check-hba-file /path/to/hba.conf > postgres --check-conf-file /path/to/postgresql.conf > (I think it's better to reuse the same postmaster executable, because > that way it's easier to have the same parsing routines.) I'd go for just postgres --check-config -D $PGDATA (In a reload scenario, you'd edit the files in-place and then do this before issuing SIGHUP.) Reasons: 1. Easier to use: one command gets you all the checks, and you can't accidentally forget to check the one config file that's gonna give you problems. 2. An in-place check is the only way to be sure that, for instance, relative-path 'include' directives are okay. 3. To implement the suggested check on role/database validity, the code is going to need to pull in the flat-file copies of pg_database etc. (Or try to contact a live postmaster, but that won't work when you don't have one.) So it needs access to $PGDATA in any case. 4. There might be usefulness in cross-checking different config files, so examining a single one out of context just seems like the wrong mindset. regards, tom lane
В списке pgsql-hackers по дате отправления: