Re: Vacuuming leaked temp tables (once again)

On Sat, 2008-07-12 at 12:04 -0400, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > Seems like it would be a fairly big patch. The temp-bootstrap process is
> > still just hand-waving though.
>
> Yeah, and it seems fairly messy. The idea I'd had was that all the
> catalog entries for (a single set of) inheritance child tables are Just
> There in the output of initdb.

Yeh, not having a temp-boostrap process at all is best.

> The tricky part is that each session that
> makes use of these tables needs to have its own copy of their contents.
> I think that could be solved with
> some magic that made their pg_class entries reflect a per-session
> relfilenode value. This seems no worse than your proposed magic in
> pg_inherit, and it eliminates the problem of needing to "bootstrap"
> all the temp-file catalog infrastructure in every session.

Agreed.

Perhaps the magic would be to create sub-directories in the pg_temp
namespace based upon backend pid. That way all relfilenode values would
be the same, but would refer to different objects.

Side thought... We can't generate Oids in Hot Standby mode, since
they'll end up duplicating values from the primary. We probably need to
reserve the top 16384 Oid values for use as temp object Oids.

> (I note that this is real close to the SQL spec's notion of how a temp
> table works --- maybe we could usefully combine this with a patch to
> provide spec-compliant temp tables?)

Yeh, I read that and thought something similar. But we're talking about
temp additions to catalog tables, not all temp tables. If we tried to
implement spec-compliant temp tables we would need to write to catalog
tables again, which is what we are trying to avoid!

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support