On Sat, Feb 28, 2015 at 11:41 AM, Stephen Frost <sfrost@snowman.net> wrote:
> Pavel,
>
> * Pavel Stehule (pavel.stehule@gmail.com) wrote:
>> 2015-02-27 22:26 GMT+01:00 Tom Lane <tgl@sss.pgh.pa.us>:
>> > Stephen Frost <sfrost@snowman.net> writes:
>> > > Right, we also need a view (or function, or both) which provides what
>> > > the *active* configuration of the running postmaster is. This is
>> > > exactly what I was proposing (or what I was intending to, at least) with
>> > > pg_hba_active, so, again, I think we're in agreement here.
>> >
>> > I think that's going to be a lot harder than you realize, and it will have
>> > undesirable security implications, in that whatever you do to expose the
>> > postmaster's internal state to backends will also make it visible to other
>> > onlookers; not to mention probably adding new failure modes.
>>
>> we can do copy of pg_hba.conf somewhere when postmaster starts or when it
>> is reloaded.
>
> Please see my reply to Tom. There's no trivial way to reach into the
> postmaster from a backend- but we do get a copy of whatever the
> postmaster had when we forked, and the postmaster only reloads
> pg_hba.conf on a sighup and that sighup is passed down to the children,
> so we simply need to also reload the pg_hba.conf in the children when
> they get a sighup.
>
> That's how postgresql.conf is handled, which is what pg_settings is
> based off of, and I believe is the behavior folks are really looking
> for.
Loading pg_hba.conf during SIGHUP in the backends will solve the
problem of displaying the
data which is not yet loaded. This change may produce a warning if it
fails to load pg_hba.conf in the backends.
Here I attached the updated patch. I didn't yet added the pg_hba_check function.
I feel it is better to be a separate patch. I can share the same later.
Regards,
Hari Babu
Fujitsu Australia