Re: Thoughts on pg_hba.conf rejection
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Alvaro Herrera <alvherre@commandprompt.com>, Simon Riggs <simon@2ndquadrant.com>, Stephen Frost <sfrost@snowman.net>, Bruce Momjian <bruce@momjian.us>, Aidan Van Dyk <aidan@highrise.ca>, Joshua Tolley <eggyknap@gmail.com>, pgsql-hackers@postgresql.org
Date: 2010-04-20T19:35:08Z
Lists: pgsql-hackers
On Tue, Apr 20, 2010 at 2:24 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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. Fine. > 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.) I think that's OK. > 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. ...Robert