Re: [HACKERS] unnailing shared relations (was Re: global temporary tables)
Excerpts from Robert Haas's message of vie may 21 10:20:38 -0400 2010: Actually, there's another way we could do this. Instead of creating pg_shared_class and pg_shared_attribute and moving all of the catalog entries for the shared relations into those tables, we could consider leaving the catalog entries in the unshared copies of pg_class, pg_attribute, etc. and DUPLICATING them in a shared catalog which would only be used prior to selecting a database. Once we selected a database we'd switch to using the database-specific pg_class et al. Obviously that's a little grotty but it might (?) be easier, and possibly a step along the way. Uh, how does this work when you change the entries for shared relations in a database-specific pg_class? Keeping everything in sync seems hard, if not impossible. -- Álvaro Herrera alvhe...@alvh.no-ip.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unnailing shared relations (was Re: global temporary tables)
On Mon, May 24, 2010 at 4:23 PM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote: Excerpts from Robert Haas's message of vie may 21 10:20:38 -0400 2010: Actually, there's another way we could do this. Instead of creating pg_shared_class and pg_shared_attribute and moving all of the catalog entries for the shared relations into those tables, we could consider leaving the catalog entries in the unshared copies of pg_class, pg_attribute, etc. and DUPLICATING them in a shared catalog which would only be used prior to selecting a database. Once we selected a database we'd switch to using the database-specific pg_class et al. Obviously that's a little grotty but it might (?) be easier, and possibly a step along the way. Uh, how does this work when you change the entries for shared relations in a database-specific pg_class? Keeping everything in sync seems hard, if not impossible. Well, I might be missing something here, but pg_class already IS database-specific. If you change anything very significant about a shared rel in one copy of pg_class today, you're toast, IIUC. This proposal doesn't make that any better, but I don't think it makes it any worse either. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unnailing shared relations (was Re: global temporary tables)
Excerpts from Robert Haas's message of lun may 24 17:18:21 -0400 2010: On Mon, May 24, 2010 at 4:23 PM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote: Excerpts from Robert Haas's message of vie may 21 10:20:38 -0400 2010: Uh, how does this work when you change the entries for shared relations in a database-specific pg_class? Keeping everything in sync seems hard, if not impossible. Well, I might be missing something here, but pg_class already IS database-specific. If you change anything very significant about a shared rel in one copy of pg_class today, you're toast, IIUC. This proposal doesn't make that any better, but I don't think it makes it any worse either. I thought the whole point of this exercise was precisely to avoid this sort of problem. -- Álvaro Herrera alvhe...@alvh.no-ip.org -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unnailing shared relations (was Re: global temporary tables)
On Mon, May 24, 2010 at 5:37 PM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote: Excerpts from Robert Haas's message of lun may 24 17:18:21 -0400 2010: On Mon, May 24, 2010 at 4:23 PM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote: Excerpts from Robert Haas's message of vie may 21 10:20:38 -0400 2010: Uh, how does this work when you change the entries for shared relations in a database-specific pg_class? Keeping everything in sync seems hard, if not impossible. Well, I might be missing something here, but pg_class already IS database-specific. If you change anything very significant about a shared rel in one copy of pg_class today, you're toast, IIUC. This proposal doesn't make that any better, but I don't think it makes it any worse either. I thought the whole point of this exercise was precisely to avoid this sort of problem. Short answer: Nope. Long answer: It would be nice to do that, but in order to accomplish that we would need to create pg_shared_foo for all relevant pg_foo and teach the backend code to check both tables in every case. That seemed hard, so I suggested just duplicating the entries, thereby giving processes like the autovacuum launcher the ability to look at any shared relation without it needing to be nailed, but not actually solving the whole problem. It may be a bad idea. It was just a thought. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unnailing shared relations (was Re: global temporary tables)
Robert Haas robertmh...@gmail.com writes: On Mon, May 24, 2010 at 5:37 PM, Alvaro Herrera alvhe...@alvh.no-ip.org wrote: Excerpts from Robert Haas's message of lun may 24 17:18:21 -0400 2010: Well, I might be missing something here, but pg_class already IS database-specific. If you change anything very significant about a shared rel in one copy of pg_class today, you're toast, IIUC. This proposal doesn't make that any better, but I don't think it makes it any worse either. I thought the whole point of this exercise was precisely to avoid this sort of problem. Short answer: Nope. In practice, it's very difficult to change anything about a system catalog anyway, because so many of its properties are baked into the behavior of the C code. Whether there's a single copy of the catalog rows is the least of your worries there. Long answer: It would be nice to do that, but in order to accomplish that we would need to create pg_shared_foo for all relevant pg_foo and teach the backend code to check both tables in every case. That seemed hard, so I suggested just duplicating the entries, thereby giving processes like the autovacuum launcher the ability to look at any shared relation without it needing to be nailed, but not actually solving the whole problem. I hadn't been paying that much attention to this thread, but it's sounding to me like it's based on a false premise. Having a shared copy of the catalog entries for a shared catalog would accomplish little or nothing in terms of eliminating nailed relcache entries. You might be able to de-nail pg_database and friends, but only at the cost of instead nailing up entries for pg_shared_class and friends. Which seems to me like a net step backwards in terms of the maintenance overhead for relcache entries. If we really cared about not nailing these (and I'm not aware of any evidence that we should care), it would probably be more useful to try to institute an intermediate level of nailing (stapling? scotch-taping?) that locked the entry into memory only until we'd finished bootstrapping the backend. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] unnailing shared relations (was Re: global temporary tables)
On Sat, Apr 24, 2010 at 6:53 PM, Robert Haas robertmh...@gmail.com wrote (in reply to Tom Lane): If we create, e.g. pg_shared_class and pg_shared_attribute, then we can un-nail the catalogs you just nailed to make the authentication process able to work without selecting a database. Actually, there's another way we could do this. Instead of creating pg_shared_class and pg_shared_attribute and moving all of the catalog entries for the shared relations into those tables, we could consider leaving the catalog entries in the unshared copies of pg_class, pg_attribute, etc. and DUPLICATING them in a shared catalog which would only be used prior to selecting a database. Once we selected a database we'd switch to using the database-specific pg_class et al. Obviously that's a little grotty but it might (?) be easier, and possibly a step along the way. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unnailing shared relations (was Re: global temporary tables)
2010/5/21 Robert Haas robertmh...@gmail.com: On Sat, Apr 24, 2010 at 6:53 PM, Robert Haas robertmh...@gmail.com wrote (in reply to Tom Lane): If we create, e.g. pg_shared_class and pg_shared_attribute, then we can un-nail the catalogs you just nailed to make the authentication process able to work without selecting a database. Actually, there's another way we could do this. Instead of creating pg_shared_class and pg_shared_attribute and moving all of the catalog entries for the shared relations into those tables, we could consider leaving the catalog entries in the unshared copies of pg_class, pg_attribute, etc. and DUPLICATING them in a shared catalog which would only be used prior to selecting a database. Once we selected a database we'd switch to using the database-specific pg_class et al. Obviously that's a little grotty but it might (?) be easier, and possibly a step along the way. I did it - just on syscache level - but there are problem with refresh. I though about some special pseudo persistent data pages attached to possible any table with temp data. Then you don't need modify any on higher level, you don't need new catalog entries, etc .. Regards Pavel Stehule -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] unnailing shared relations (was Re: global temporary tables)
On Fri, May 21, 2010 at 11:10 AM, Pavel Stehule pavel.steh...@gmail.com wrote: 2010/5/21 Robert Haas robertmh...@gmail.com: On Sat, Apr 24, 2010 at 6:53 PM, Robert Haas robertmh...@gmail.com wrote (in reply to Tom Lane): If we create, e.g. pg_shared_class and pg_shared_attribute, then we can un-nail the catalogs you just nailed to make the authentication process able to work without selecting a database. Actually, there's another way we could do this. Instead of creating pg_shared_class and pg_shared_attribute and moving all of the catalog entries for the shared relations into those tables, we could consider leaving the catalog entries in the unshared copies of pg_class, pg_attribute, etc. and DUPLICATING them in a shared catalog which would only be used prior to selecting a database. Once we selected a database we'd switch to using the database-specific pg_class et al. Obviously that's a little grotty but it might (?) be easier, and possibly a step along the way. I did it - just on syscache level - but there are problem with refresh. I though about some special pseudo persistent data pages attached to possible any table with temp data. Then you don't need modify any on higher level, you don't need new catalog entries, etc .. I don't think we're talking about the same thing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
