Simon Riggs <[EMAIL PROTECTED]> writes:
> So it would seem that we need a way of handling temp tables that doesn't
> rely on catalog entries at all.
That's a complete non-starter; I need go no farther than to point out
that it would break clients that expect to see their temp tables
reflected in pg_class and so forth.
There's been some idle musing in the past about causing pg_class and
friends to have inheritance-child tables that are "temp", both in the
sense of being backend-local and of not having guaranteed storage,
and arranging to store the rows needed for a backend's temp tables
in there. There's still a long way to go to make that happen, but
at least it would be reasonably transparent on the client side.
> Are we also at risk from very long lived sessions that use temp tables?
Yeah, one of the bigger problems with it is that no one else could
even see whether a backend's temp table was at risk of wraparound
(or even before actual wraparound, in need of freezing because pg_clog
is supposed to be truncated). Possibly a backend could advertise a
min frozen xid for its temp tables in the PGPROC array.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
