Excerpts from Robert Haas's message of vie ago 06 15:32:21 -0400 2010: > > Perhaps run through pg_class after restart and flush anything marked > > relistemp? > > The trouble is that you have to bind to a database before you can run > through pg_class, and the postmaster doesn't. Of course, if it could > attach to a database and then detach again, this might be feasible, > although perhaps still a bit overly complex for the postmaster, but in > any event it doesn't.
A simpler idea seems to run a process specifically to connect to the database to scan pg_class there, and then die. It sounds a tad expensive though. > I've been thinking about that, but it's a bit challenging to imagine > how it could work. It's not just the pg_class entries you have to > think about, but also pg_attrdef, pg_attribute, pg_constraint, > pg_description, pg_index, pg_rewrite, and pg_trigger. An even > stickier problem is that we have lots of places in the backend code > that refer to objects by OID. We'd either need to change all of that > code (which seems like a non-starter) or somehow guarantee that the > OIDs assigned to any given backend's private objects would be > different from those assigned to any public object (which I also don't > see how to do). Maybe we could reserve one of the 32 bits of OID to indicate private-ness. -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
