Thread: Making temp tables' toast tables be temp

Currently, a toast table attached to a temporary table is treated much
as though it were a regular permanent table: accesses to it go through
shared buffers and are WAL-logged.  Aside from the obvious performance
penalties, this means that backends may sometimes acquire open file
pointers for temporary toast tables of other backends, which can have
unpleasant consequences.  Yesterday someone reported running out of
disk space because of dangling references to nominally-dropped temp
tables:
http://archives.postgresql.org/pgsql-bugs/2007-07/msg00122.php

So I'm thinking it might be time to fix this.  After checking the
code, it seems like it'd be a reasonably small patch if we establish
a convention that toast tables for a temp schema pg_temp_nnn are
kept in an associated dedicated schema, named something like
pg_temp_nnn_toast or pg_toast_temp_nnn.  Then functions like
isOtherTempNamespace() could still recognize these tables as temp.
It'd mean a bit more clutter in pg_namespace though.

Comments?
        regards, tom lane

"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> So I'm thinking it might be time to fix this.  After checking the
> code, it seems like it'd be a reasonably small patch if we establish
> a convention that toast tables for a temp schema pg_temp_nnn are
> kept in an associated dedicated schema, named something like
> pg_temp_nnn_toast or pg_toast_temp_nnn.  Then functions like
> isOtherTempNamespace() could still recognize these tables as temp.
> It'd mean a bit more clutter in pg_namespace though.

Why not just in the same pg_temp namespace?

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com

Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> So I'm thinking it might be time to fix this.  After checking the
>> code, it seems like it'd be a reasonably small patch if we establish
>> a convention that toast tables for a temp schema pg_temp_nnn are
>> kept in an associated dedicated schema, named something like
>> pg_temp_nnn_toast or pg_toast_temp_nnn.  Then functions like
>> isOtherTempNamespace() could still recognize these tables as temp.
>> It'd mean a bit more clutter in pg_namespace though.

> Why not just in the same pg_temp namespace?

Well, there's a risk of collisions with user table names; not a big
risk maybe but not nil.  Also, that would be in the search path,
making the toast tables "visible" so that they'd be displayed by
things like psql's \dt.  Keeping toast tables in their own schema
that's not in the path has worked well for us since 7.3, and I don't
want to give it up.

Any thoughts about which naming convention to use?  pg_temp_nnn_toast or
pg_temp_toast_nnn would emphasize the "temp-ness" while pg_toast_temp_nnn
would emphasize the "toast-ness".  It'd be roughly the same as far as
the backend is concerned (since it mostly deals with OIDs not names
anyway), and I'm not too sure whether any client-side code would care
or what its preference would be.
        regards, tom lane