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

From Simon Riggs
Subject Re: Vacuuming leaked temp tables (once again)
Date
Msg-id 1215819708.4051.1678.camel@ebony.2ndQuadrant
Whole thread Raw
In response to Re: Vacuuming leaked temp tables (once again)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Vacuuming leaked temp tables (once again)
List pgsql-hackers
On Fri, 2008-07-11 at 17:26 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.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/

> 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.

OK, very cool if we could make it work. I realised it would have to
apply all the way through to pg_statistic.

Brain dump a little more, while we're on the subject? This aspect is
something I've not spent any time on yet, so even a few rungs up the
ladder will help lots. Thanks.

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



pgsql-hackers by date:

Previous
From: Teodor Sigaev
Date:
Subject: Re: [PATCHES] GIN improvements
Next
From: Tom Lane
Date:
Subject: Re: PATCH: CITEXT 2.0 v3