From: Stephen Frost <sfrost@snowman.net>
To: Greg Stark <stark@mit.edu>
Cc: Haribabu Kommi <kommi.haribabu@gmail.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Providing catalog view to pg_hba.conf file - Patch submission
Date: Mon, 2 Mar 2015 08:34:17 -0500
Message-ID: <20150302133417.GL29780@tamriel.snowman.net> (raw)
In-Reply-To: <CAM-w4HOFSCLk_erqxLOjbu9dv3vGcuC5RuCOi5C0y-GKL+j8_w@mail.gmail.com>
References: <20150227165950.GP29780@tamriel.snowman.net>
<CAFj8pRBo6n4gEQV8J72R0_iXiCa-kZ+j1Ecwk+LrjZRJFN4PhQ@mail.gmail.com>
<20150227183236.GQ29780@tamriel.snowman.net>
<CAFj8pRD0GmDAf-4M8U=JyuDRUn5n1W3HCbL2oaKDbasLKwU4zw@mail.gmail.com>
<20150227195529.GS29780@tamriel.snowman.net>
<12545.1425072391@sss.pgh.pa.us>
<CAFj8pRBctY5wDOfQB+anSd-EkqJV4usJMLiiMk2GXZeeOAWMdw@mail.gmail.com>
<20150228004101.GV29780@tamriel.snowman.net>
<CAJrrPGedf9TrbCYS7QXtLrFSWp79k6La06z7J_V9r1B_SnWKzg@mail.gmail.com>
<CAM-w4HOFSCLk_erqxLOjbu9dv3vGcuC5RuCOi5C0y-GKL+j8_w@mail.gmail.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Greg,
* Greg Stark (stark@mit.edu) wrote:
> On Mon, Mar 2, 2015 at 6:36 AM, Haribabu Kommi <kommi.haribabu@gmail.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
Attachments:
signature.asc (application/pgp-signature, 818B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: sfrost@snowman.net, stark@mit.edu, kommi.haribabu@gmail.com, pavel.stehule@gmail.com, tgl@sss.pgh.pa.us, tomas.vondra@2ndquadrant.com
Subject: Re: Providing catalog view to pg_hba.conf file - Patch submission
In-Reply-To: <20150302133417.GL29780@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox