From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Joshua Tolley <eggyknap(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Thoughts on pg_hba.conf rejection |
Date: | 2010-04-20 18:24:35 |
Message-ID: | 17080.1271787875@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> ... So we could solve both this and
> the original complaint in the thread if we can arrange for all
> authentication to be done on the basis of shared-catalog access under
> rules similar to what the AV launcher does with pg_database. At a
> minimum that will require marking the pg_auth catalogs as
> BKI_SCHEMA_MACRO, but that's far less painful than it used to be.
> I don't recall what other consequences there are, but will go looking.
I've been looking at this and it seems do-able, though I don't have
working code yet. Downsides appear to be:
1. We'd have to force an initdb because of a couple of small catalog
changes. This doesn't seem like a showstopper at this phase of the
release cycle, but it's slightly annoying. pg_migrator could be used
if anyone's really in need of it.
2. We don't have infrastructure that would allow access to out-of-line
toasted fields during startup. Rather than try to add such, I propose
removing pg_authid's toast table, with the consequence that rolpassword
cannot be long enough to require out-of-line storage (note it could
still be compressed in-line). I cannot imagine any real situation where
this would be an issue --- does anyone else? (BTW, I'm fairly sure that
we couldn't support an out-of-line rolpassword in the past anyway,
because of restrictions in the old flatfiles code.)
3. We'd have to nail pg_authid, pg_auth_members, and their indexes into
relcache, because relcache.c isn't prepared to cope otherwise. I doubt
this would affect performance in any material way, but it would eat a
few more kbytes of storage per backend.
None of these seem like reasons not to do it. Objections?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2010-04-20 18:31:47 | Re: BETA |
Previous Message | Pavel | 2010-04-20 17:59:52 | Re: GSoC - proposal - Materialized Views in PostgreSQL |