Re: Thoughts on pg_hba.conf rejection

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Tom Lane escribió:
>> 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.)

> In the past rolconfig could have been a problem too, but fortunately we
> got that moved out. I really doubt that a password of "only" about 2kB
> compressed is going to be a limitation to anyone on this planet. (Hmm,
> isn't it really 8kB in row length that's the hard limit?)

Actually, rolconfig would be OK because it doesn't have to be accessed
until after we've completed authentication. However there's no really
nice way to ensure that rolpassword doesn't get toasted if another
column can be. I suppose we could have initdb force its attstorage to
PLAIN or some such.

> This could perhaps be an issue if we were to store an SSL certificate in
> rolpassword or something like that, but I don't think we support that.

Nope, not that I know of. Anyway we could solve the problem if it ever
came up --- I don't think there's anything insurmountable about
accessing shared toast tables here, we'd just need some support to allow
them to be nailed-in-cache.

>> 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.

> This doesn't limit that VACUUM FULL or other commands are applied to
> those catalogs, right?

Nope, it's no different from pg_database.

Attached is a draft patch --- it looks pretty reasonable, but I've not
tested the impact on walsender yet.

regards, tom lane