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
