Re: Providing catalog view to pg_hba.conf file - Patch submission

Greg,

* Greg Stark (stark(at)mit(dot)edu) wrote:
> On Mon, Mar 2, 2015 at 6:36 AM, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
> wrote:
>
> > 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.
>
> This seems like the right strategy to me. It parallels pg_settings and
> postgresql.conf which means one less surprising quirk for future developers.

Agreed.

> An idle thought, in the long-term it seems like it would be better to have
> postmaster have some shared memory where it dumps out a config data
> structure that backends can all see. That might help with the
> race-conditions we have now when reloading config data where different
> backends could end up with different interpretations of the same config or
> even see different configs if the files are being modified concurrently.

I had considered this option also but threw it out almost as quickly as
it came to mind..

> But I think that would have to be done very carefully so the postmaster
> doesn't sacrifice any reliability.

Due to this. I'm not sure there's any trivial way to ensure that. I
suppose we could use mmap() and then mprotect() the region when we're
not reloading it in the postmaster, and make sure that it's PROT_READ
when we fork() as I *think* that would be preserved in the child,
until/unless the child changed it. That the child could change it is
certainly a concern, even if it requires a few extra steps, but it'd at
least be better than nothing, and if there's no code in the child which
ever calls mprotect, well, perhaps it'd be good enough.

Obviously, this would be a much larger change and we'd have to use a
lock-free structure to make sure that the children don't read something
inconsistent and avoid having to use a lock that could cause problems
for the postmaster.

Thanks!

Stephen