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

From: Greg Stark <stark(at)mit(dot)edu>
To: Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Providing catalog view to pg_hba.conf file - Patch submission
Date: 2015-03-02 12:51:59
Message-ID: CAM-w4HOFSCLk_erqxLOjbu9dv3vGcuC5RuCOi5C0y-GKL+j8_w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.
But I think that would have to be done very carefully so the postmaster
doesn't sacrifice any reliability.

--
greg

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2015-03-02 12:56:06 Re: Redesigning checkpoint_segments
Previous Message Shigeru Hanada 2015-03-02 12:48:27 Re: Join push-down support for foreign tables