Re: Parsing of pg_hba.conf and authentication inconsistencies - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Parsing of pg_hba.conf and authentication inconsistencies
Date
Msg-id 489861C2.6090808@hagander.net
Whole thread Raw
In response to Re: Parsing of pg_hba.conf and authentication inconsistencies  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Parsing of pg_hba.conf and authentication inconsistencies  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
>> Should I read this as you warming up slightly to the idea of having the
>> postmaster do that? ;-)
> 
> No ;-).  

Bummer. Worth a shot though :-)


> I still think that a "postgres --check-config" feature would be
> far more complete and useful, as well as less likely to cause bugs in
> critical code paths.

I still think we should have both :-)


> A point that I don't think has been made so far in the thread: the
> only place the postmaster could complain in event of problems is the
> postmaster log, which we know too well isn't watched by inexperienced
> DBAs.  I guarantee you that we will get bug reports along the lines of
> "I updated pg_hba.conf and did pg_ctl reload, but nothing changed!
> Postgres sucks!" if we implement checking at load time.  I think one of
> the main advantages of a --check-config approach is that whatever it had
> to say would come out on the user's terminal.

How is this different from how we deal with postgresql.conf today? That
one can only log errors there as well, no? (And has a lot more complex
code to get there)

Which would also be helped byu a --check-config approach, of course -
I'm not saying we shouldn't have that, just that I want us to have both :-)


//Magnus


pgsql-hackers by date:

Previous
From: Gregory Stark
Date:
Subject: Re: searching bison guru - grouping sets implementation
Next
From: Dimitri Fontaine
Date:
Subject: Re: Automatic Client Failover