Re: Vacuuming leaked temp tables (once again)

On Sat, 2008-07-12 at 00:57 +0100, Dave Page wrote:
> On Sat, Jul 12, 2008 at 12:41 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> >
> > On Fri, 2008-07-11 at 17:26 -0400, Tom Lane wrote:
> >> Simon Riggs <simon(at)2ndquadrant(dot)com> 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.
> >
> > What does the SQL Standard say about the Information Schema I wonder/
>
> Many apps were written long before we had one. Not too mention that it
> doesn't provide anything like all the info that PostgreSQL-specific
> tool (though not necessarily user apps) would likely need.

So are you saying

a) that other sessions need to be able to see pg_class entries for
temporary tables created by different sessions?

b) that you need to be able to see pg_class entries for temporary tables
created only in your session?

Hopefully you just mean (b)??

a) would simply not be possible at the same time as having us avoid
pg_class writes in Hot Standby mode. We would have a choice of seeing
temp tables, or allowing temp tables to work in Hot Standby, not both.

b) would is possible, if we follow the route of taking a locally
inherited copy of pg_class.

The SQL Standard Information Schema does show LOCAL TEMPORARY and GLOBAL
TEMPORARY tables. Our implementation of temp tables differs from the
standard, so I think (b) is fully in line with that.

If anybody did want (a), then I'd suggest that we use the keyword GLOBAL
TEMPORARY table to denote something that would be put in pg_class and
visible to all, and thus unusable in hot standby mode. I'm not planning
on building that.

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