Re: Thoughts on pg_hba.conf rejection

Tom Lane escribió:

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

check

> 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?)

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.

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

> None of these seem like reasons not to do it. Objections?

None here.

--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support