Thoughts on pg_hba.conf rejection
in [PgSql]
|
From: Robert Haas on 20 Apr 2010 18:12 On Tue, Apr 20, 2010 at 5:51 PM, Robert Haas <robertmhaas(a)gmail.com> wrote: > On Tue, Apr 20, 2010 at 5:02 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> Robert Haas <robertmhaas(a)gmail.com> writes: >>> On Tue, Apr 20, 2010 at 2:24 PM, Tom Lane <tgl(a)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. > > Well that just begs the question - why do we need a hard-wired > descriptor? Presumably we should only need to hard-wired descriptors > for the relations are used by the relcache code itself to build more > descriptors - so clearly pg_cache and pg_attribute, but beyond that I > don't get it. In particular, I can't see any reason why we couldn't > just build the descriptor for pg_authid etc. by scanning pg_class and > pg_attribute. I suppose the problem here is that pg_attribute and pg_class are not shared catalogs, so we can't read them without selecting a database. What about making a fake version of these relations that includes only the shared catalogs? ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 20 Apr 2010 18:48 Robert Haas escribi�: > I suppose the problem here is that pg_attribute and pg_class are not > shared catalogs, so we can't read them without selecting a database. > What about making a fake version of these relations that includes only > the shared catalogs? Hmm, interesting. I wonder if something of this sort would allow one to create a shared relation at the user level -- right now the set of shared relations is hardcoded so this cannot work. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 20 Apr 2010 19:13 Robert Haas <robertmhaas(a)gmail.com> writes: > I suppose the problem here is that pg_attribute and pg_class are not > shared catalogs, so we can't read them without selecting a database. Among other things. > What about making a fake version of these relations that includes only > the shared catalogs? Well, after you solve the few dozen problems standing in the way of that, go right ahead. I'm not holding up 9.0 for it though. (You might want to look back at the archived discussions about how to avoid storing entries for temp tables in these catalogs; that poses many of the same issues.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 21 Apr 2010 00:14 On Tue, Apr 20, 2010 at 7:13 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> I suppose the problem here is that pg_attribute and pg_class are not >> shared catalogs, so we can't read them without selecting a database. > > Among other things. > >> What about making a fake version of these relations that includes only >> the shared catalogs? > > Well, after you solve the few dozen problems standing in the way > of that, go right ahead. I'm not holding up 9.0 for it though. > > (You might want to look back at the archived discussions about how to > avoid storing entries for temp tables in these catalogs; that poses > many of the same issues.) Do you happen to know what a good search term might be? I tried searching for things like "pg_class temp tables" and "pg_class temporary tables" and didn't come up with much. The closest thing I found was a discussion about global temp tables (subject aws "idea: global temp tables") in which Greg Stark was arguing that there wasn't much point in implementing them without solving this issue (and others were disagreeing) but it didn't get into any of the technical issues at all. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 21 Apr 2010 10:50
Robert Haas <robertmhaas(a)gmail.com> writes: > On Tue, Apr 20, 2010 at 7:13 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >> (You might want to look back at the archived discussions about how to >> avoid storing entries for temp tables in these catalogs; that poses >> many of the same issues.) > Do you happen to know what a good search term might be? I tried > searching for things like "pg_class temp tables" and "pg_class > temporary tables" and didn't come up with much. I found this thread: http://archives.postgresql.org/pgsql-hackers/2008-07/msg00593.php I claimed in that message that there were previous discussions but I did not come across them right away. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |