Date: Mon, 2 Mar 2015 08:34:17 -0500
From: Stephen Frost <sfrost@snowman.net>
To: Greg Stark <stark@mit.edu>
Cc: Haribabu Kommi <kommi.haribabu@gmail.com>,
 Pavel Stehule <pavel.stehule@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>,
 Tomas Vondra <tomas.vondra@2ndquadrant.com>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Providing catalog view to pg_hba.conf file - Patch submission
Message-ID: <20150302133417.GL29780@tamriel.snowman.net>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="gepL2JgcC5Q6nP6x"
Content-Disposition: inline
In-Reply-To: 
 <CAM-w4HOFSCLk_erqxLOjbu9dv3vGcuC5RuCOi5C0y-GKL+j8_w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


--gepL2JgcC5Q6nP6x
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Greg,

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

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

--gepL2JgcC5Q6nP6x
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCgAGBQJU9GbZAAoJEO1sijiDR2RVg/YP/3RZu9Qq81X+++Q26cn0z+vK
Kq4WHnXWs4b7xRKg8CgMEDrDnKDIIZDEPlL9ni4UrFHlF+XmVnX66hTeZwUJW8F2
YX+L42m5vCE/Uvpn+F1bElfqI/LhMkNohiGIIl5cLcnVsRCz2x6pq6cxzAf4P4hr
SasmQD+Alcp2qb6T63I0RNKqsidDKF33KWakldGepg1yJtRPwoCggraZDlxn/YUz
AYufVW+VaeQAGcLyt0ivPd9y7FVKYitH6QzlMrBQCjcsxhR8AK8xvKaBzuMDfUAn
S/SSoK6nLqTJwk7jk2mCt/v/UQNF7WeVkuDpQ0ApSOy7j5QGd0ucoAk7AXFhxPrP
GZygFCFGnk5YCAv0ZQrEHRuGjbyFldQhPe/yfXU80fMSECTm2z8BST9BaiNq+xFA
pYYKSWv77R1cv4IcYLXH6OVD1gFUID8vQhrJVbHFwJ/UM4VbgSVxK+6BvCmRSJ4M
LdLJdSS9NoI+yAIFoYedaHSv2oVU9Nh8AR5Uou8Lr4hywscBsD9TGD03UIyFGIFW
WTkg62j3XNXztOraCCn2X/S92NVK6ozffOYK9fK6iIzLkntVuhQKZVBGbGOERYeA
jTXLZQaliLXOFN/UZWeAsFCvjIJr5O2rucehoZ/ezCDp1KZA6oNmKBaYkgJvx+sN
5iyF109a5BSYrrjGOrs+
=1+Mw
-----END PGP SIGNATURE-----

--gepL2JgcC5Q6nP6x--