Re: Thoughts on pg_hba.conf rejection - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Thoughts on pg_hba.conf rejection
Date
Msg-id 29529.1271797342@sss.pgh.pa.us
Whole thread Raw
In response to Re: Thoughts on pg_hba.conf rejection  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Thoughts on pg_hba.conf rejection
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Apr 20, 2010 at 2:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.

> Hmm, I'm not sure I understand why this is necessary or what our other
> options are.

relcache.c assumes that "critical" relations (those for which we have
hard-wired descriptors in schemapg.h) are always nailed-in-cache.  In
the general case this is necessary because we'd not be able to rebuild
the cache entry if it got discarded; eg, without a pg_class entry you're
dead in the water.  It's possible we could decouple these attributes;
for instance develop a notion of being nailed only until authentication
finishes, or something like that.  I'm not thinking it's worth it
though.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Vacuum cancels autovacuum error message confusing?
Next
From: Josh Berkus
Date:
Subject: Re: Vacuum cancels autovacuum error message confusing?