Re: global temporary tables - Mailing list pgsql-hackers

From Robert Haas
Subject Re: global temporary tables
Date
Msg-id q2q603c8f071004232046s1b77edeeib8289ecc7556c762@mail.gmail.com
Whole thread Raw
In response to Re: global temporary tables  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: global temporary tables  ("Greg Sabino Mullane" <greg@turnstep.com>)
List pgsql-hackers
On Fri, Apr 23, 2010 at 11:28 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Fri, Apr 23, 2010 at 11:11 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I also kind of wonder what is supposed to happen if someone DROPs or
>>> ALTERs the temp table definition ...
>
>> ...not so much.  Here you REALLY want a DROP attempt to acquire an
>> AccessExclusiveLock that will conflict with any outstanding
>> AccessShareLocks.  Similarly, you're only going to be able to modify
>> the schema for the relation if it's not otherwise in use.
>
> I think you're presuming the answer to the question.  We could also view
> the desired behavior as being that each session clones the temp table
> definition at some instant (eg, first use).  The approach that you're
> assuming seems fraught with large downsides: in particular, implementing
> ALTER TABLE would be a mess.  The would-be alterer would need access to
> the physical copies of all sessions, which throws out not only the
> assumption that the relmapper entries can be private data, but all of
> the access optimizations we currently have in the local buffer manager.

I agree, that would be pretty unfortunate, althogh maybe it's the only
way to make it work.  It's not what I had in mind.  I was thinking
that the would-be ALTERER could just take an AccessExclusiveLock, but
now that I think about it that doesn't work, since a backend could
have the table unlocked between transactions but still have private
contents in it.  :-(

> Not to mention the coding mess of having to repeat the ALTER operation
> for each of N copies, some of which might disappear while we're trying
> to do it (or if they don't, we're blocking backends from exiting).
> I don't even know how you'd do the ALTER over again N times if you
> only have one set of catalog entries describing the N copies.

Well, if you clone the table, that just pushes the problem around.
When I run ALTER TABLE on one of these thingamabobs, does it modify my
clone?  The original?  Both?  If it modifies my clone, how do we
modify the original?  If it modifies the original, won't I be rather
surprised to find my clone unaffected?  If it modifies both, how do we
avoid complete havoc if the original has since been modified (perhaps
incompatibly, perhaps not) by some other backend doing its own ALTER
TABLE?

...Robert


pgsql-hackers by date:

Previous
From: Rod Taylor
Date:
Subject: CIText and pattern_ops
Next
From: Pavel Stehule
Date:
Subject: Re: global temporary tables