Re: Vacuuming leaked temp tables (once again) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Vacuuming leaked temp tables (once again)
Date
Msg-id 15328.1215878671@sss.pgh.pa.us
Whole thread Raw
In response to Re: Vacuuming leaked temp tables (once again)  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Vacuuming leaked temp tables (once again)
List pgsql-hackers
Simon Riggs <simon@2ndquadrant.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.  The tricky part is that each session that
makes use of these tables needs to have its own copy of their contents.
(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?)  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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: Vacuuming leaked temp tables (once again)
Next
From: Simon Riggs
Date:
Subject: Re: Vacuuming leaked temp tables (once again)