From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parsing of pg_hba.conf and authentication inconsistencies |
Date: | 2008-08-02 16:49:00 |
Message-ID: | 4550.1217695740@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)commandprompt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-08-02 17:04:38 | Re: Parsing of pg_hba.conf and authentication inconsistencies |
Previous Message | Magnus Hagander | 2008-08-02 16:39:27 | Re: Parsing of pg_hba.conf and authentication inconsistencies |