Skip site navigation (1) Skip section navigation (2)

Re: Transactions and temp tables

From: Emmanuel Cecchet <manu(at)frogthinker(dot)org>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Transactions and temp tables
Date: 2008-12-02 03:00:48
Message-ID: 4934A4E0.8080208@frogthinker.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Heikki,

I have extended the patch to allow temp tables that have been 
created/dropped within the same transaction (and also on commit drop).
There is a problem with temp tables with on delete rows that are created 
inside a transaction.
Take the 2pc_on_delete_rows_transaction.sql test case and change the 
creation statement, instead of
create temp table foo(x int) on commit delete rows;
try
create temp table foo(x serial primary key) on commit delete rows;

The test will fail. It looks like the onCommit field is not properly 
updated when serial or primary key is used in that context. I did not 
figure out why.

Waiting for your feedback
Emmanuel


Emmanuel Cecchet wrote:
> I think that the Assert in is_temp_rel(Oid) in tablecmds.c should be 
> replaced by if (on_commits == NULL) return false;
> As the use case below shows, a regular table can be created and hold a 
> LOCKTAG_RELATION lock that will trigger the call to is_temp_rel in 
> is_preparable_locktag. The assert will break if no temp table was 
> accessed.
>
> As we were also trying to list potential issues, if the temp table 
> uses a SERIAL type, will there be potentially a problem with the 
> sequence at prepare time?
>
> Emmanuel
>
>
>> The following test fails with your patch on my system. Could you 
>> check if you can reproduce?
>>
>> psql (8.4devel)
>> Type "help" for help.
>>
>> test=# begin;
>> BEGIN
>> test=# create table paul(x int);
>> CREATE TABLE
>> test=# insert into paul values(1);
>> INSERT 0 1
>> test=# prepare transaction 'persistentTableShouldSucceed';
>> server closed the connection unexpectedly
>>        This probably means the server terminated abnormally
>>        before or while processing the request.
>> The connection to the server was lost. Attempting reset: Failed.
>>
>> ---
>>
>> LOG:  database system is ready to accept connections
>> TRAP: FailedAssertion("!(on_commits != ((void *)0))", File: 
>> "tablecmds.c", Line: 7823)
>> LOG:  server process (PID 15969) was terminated by signal 6: Aborted
>> LOG:  terminating any other active server processes
>> FATAL:  the database system is in recovery mode
>>
>>
>> Thanks,
>> manu
>>
>
>


-- 
Emmanuel Cecchet
FTO @ Frog Thinker 
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: manu(at)frogthinker(dot)org
Skype: emmanuel_cecchet


Attachment: patch-2pc-temp-table-8.4v5-withtests.zip
Description: application/octet-stream (9.6 KB)

In response to

Responses

pgsql-hackers by date

Next:From: KaiGai KoheiDate: 2008-12-02 04:42:37
Subject: [BUG] lo_open() makes a warning/falls to an assertion
Previous:From: Robert HaasDate: 2008-12-02 01:57:33
Subject: Re: broken URL in commitfest page

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group