Re: Implementation of global temporary tables?

> Sounds fine in general. I'm a bit curious to know what are the locking
implications of > vivifying the table on access.

The locking implications depend on how we interpret the existing commands
in the context of global temp tables and I think we should discuss and
agree on the behaviors of the commands with global temp tables, but I think
in general we can follow these rules:

If the command executes on the global temp table's metadata, for example an
ALTER TABLE command, then we lock the global copy at the same level as we
do a regular table.

If the command executes on the global temp table's data (which is actually
stored in the session copy), for example an DML command, then the global
copy is locked at the AccessShareLock level to prevent concurrent
modifications to the global temp table's definition from other sessions.

Thanks,
Zhaomo

On Wed, Jul 15, 2015 at 4:26 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:

>
> On 07/15/2015 07:58 AM, Simon Riggs wrote:
>
>
>> For me the design summary is this
>>
>> * CREATE GLOBAL TEMP TABLE creates catalog entries like a normal table
>> but with different relkind
>> * When we see a request to INSERT, DEL, UPD, SEL from the temp table, if
>> it does not exist we create it as a TEMP table of the same name, using the
>> Global's pg_class entry as a template
>>
>> That meets the SQL Standard and doesn't contain any visibility problems
>> or need for new internals.
>>
>> The purpose of this feature is to automatically create a temp table with
>> the same definition whenever needed. The discussion of "bloat" is just
>> wrong. We create exactly the same amount of bloat as if we had typed CREATE
>> TEMP TABLE. Optimising temp table entries in the catalog is another,
>> separate patch, if we care.
>>
>>
>>
> Sounds fine in general. I'm a bit curious to know what are the locking
> implications of vivifying the table on access.
>
> cheers
>
> andrew
>