Re: Vacuuming leaked temp tables (once again)

On Sat, 2008-07-12 at 09:56 +0100, Dave Page wrote:
> An inheritance schema for pg_class may well work for them.

OK, proposal is something like this:

We must avoid writes to many system tables to allow temp tables to
function.
Priority 1
pg_class - base definition of table
pg_attribute - columns
pg_attrdef - defaults
pg_statistic - ability to store ANALYZE and VACUUM results
pg_inherits

Priority 2 - would we need any of these?
pg_depend
pg_rules
pg_rewrite
pg_triggers
pg_indexes

Each of the above tables would have a matching temp_* version.

We wouldn't want to create a full temp schema every time we connect, we
would only do that when a temp table was created. 

When first temp table requested we create temp schema, using reserved
oids established at bootstrap time. We'll need a temp-bootstrap process
for the creation of temp_pg_class and temp_pg_attribute, then we can
create the other catalog tables more normally.

We hack find_inheritance_children() so it returns the oid of the
inherited temp catalog table for appropriate catalog tables. That way we
don't need to write to pg_inherits in order to have the catalog tables
recognise they have inheritance children.

So all direct accesses to catalog tables would result in temp tables
showing up in the result set, but only within the same session.

In Hot Standby mode we would ignore the inheritance hint and *always*
search pg_inherits every time we access a table.

Would also need to go through all catalog code so that it accessed the
correct catalog table depending upon whether its permanent or temp.

Seems like it would be a fairly big patch. The temp-bootstrap process is
still just hand-waving though.

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