Re: including backend ID in relpath of temp rels - updated patch

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 <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support