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

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Providing catalog view to pg_hba.conf file - Patch submission
Date: 2015-02-27 16:38:00
Message-ID: 54F09D68.2090700@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 28.1.2015 23:01, Jim Nasby wrote:
> On 1/28/15 12:46 AM, Haribabu Kommi wrote:
>>> >Also, what happens if someone reloads the config in the middle of
>>> running
>>> >the SRF?
>> hba entries are reloaded only in postmaster process, not in every
>> backend.
>> So there shouldn't be any problem with config file reload. Am i
>> missing something?
>
> Ahh, good point. That does raise another issue though... there might
> well be some confusion about that. I think people are used to the
> varieties of how settings come into effect that perhaps this isn't an
> issue with pg_settings, but it's probably worth at least mentioning in
> the docs for a pg_hba view.

I share this fear, and it's the main problem I have with this patch.

Currently, the patch always does load_hba() every time pg_hba_settings
is accessed, which loads the current contents of the config file into
the backend process, but the postmaster still uses the original one.
This makes it impossible to look at currently effective pg_hba.conf
contents. Damn confusing, I guess.

Also, I dare to say that having a system view that doesn't actually show
the system state (but contents of a config file that may not be loaded
yet), is wrong.

Granted, we don't modify pg_hba.conf all that often, and it's usually
followed by a SIGHUP to reload the contents, so both the backend and
postmaster should see the same stuff. But the cases when I'd use this
pg_hba_settings view usually turned out to be 'forgot to SIGHUP', so
this would not help, actually.

What I can imagine is keeping the original list (parsed by postmaster,
containing the effective pg_hba.conf contents), and keeping another list
of 'current contents' within backends. And having a 'reload' flag for
pg_hba_settings, determining which list to use.

pg_hba_settings(reload=false) -> old list (from postmaster)
pg_hba_settings(reload=true) -> new list (from backend)

The pg_hba_settings view should use 'reload=false' (i.e. show effective
contents of the hba).

The other feature that'd be cool to have is a debugging function on top
of the view, i.e. a function pg_hba_check(host, ip, db, user, pwd)
showing which hba rule matched. But that's certainly nontrivial.

--
Tomas Vondra http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Fetter 2015-02-27 16:42:29 Re: POLA violation with \c service=
Previous Message Tom Lane 2015-02-27 16:19:12 Re: star schema and the optimizer