* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost <sfr...@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.
I had been considering what it'd take (and certainly appreciated that
it's not trivial to look at the postmaster post-fork) but had also been
thinking a simpler approach might be possible (one which doesn't involve
*directly* looking at the postmaster config)- we could probably
reasonably consider whatever the backend has currently is the same as
the active configuration, provided we reload the pg_hba.conf into the
backends when a sighup is sent, just as we do with postgresql.conf.
I understand that there may be objections to that on the basis that it's
work that's (other than for this case) basically useless, but then
again, it's not like we anticipate reloads happening with a high
frequency or that we expect loading these files to take all that long.
The original patch only went off of what was in place when the backend
was started from the postmaster and the later patch changed it to just
always show what was currently in the pg_hba.conf file, but what
everyone on this thread (except those worried more about the
implementation and less about the capability) expects and wants is
"pg_settings, but for pg_hba". The way we get that is to do it exactly
the same as how we handle pg_settings.
> I think the proposed mechanism (ie read and return the current contents of
> the file) is just fine, and we should stop there rather than engineering
> this to death. We've survived twenty years with *no* feature of this
> sort, how is it suddenly essential that we expose postmaster internal
> state?
Perhaps I'm missing something, but I really don't see it to be a huge
deal to just reload pg_hba.conf in the backends when a sighup is done,
which would provide pg_settings-like results (ignoring that you can set
GUCs directly in the backend, of course), with two ways through the
function which loads the file- one which actually updates the global
setting in the backend during a sighup, and one which provides the
results in variables passed in by the caller (or similar) and allows
returning the contents of the current pg_hba.conf as parsed in an SRF.
Thanks!
Stephen
signature.asc
Description: Digital signature
