[Fwd: Re: Transactions and temp tables]

From: Emmanuel Cecchet <manu(at)asterdata(dot)com>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: [Fwd: Re: Transactions and temp tables]
Date: 2008-12-16 22:16:40
Message-ID: 494828C8.3090900@asterdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

I just saw that this new patch was not considered because the previous
version ended being rejected.
Note that this version of the patch aims at supporting ONLY temp tables
that are created AND dropped in the same transaction. We need to be able
to use temp tables in transactions that are doing 2PC, but the temp
table lifespan does not need to cross transaction boundaries.

Please let me know if this patch could be integrated in 8.4.
Thanks,
Emmanuel

-------- Original Message --------
Subject: Re: [HACKERS] Transactions and temp tables
Date: Mon, 01 Dec 2008 22:00:48 -0500
From: Emmanuel Cecchet <manu(at)frogthinker(dot)org>
Organization: Frog Thinker
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
References: <48EA7B12(dot)6050906(at)frogthinker(dot)org>
<48EB0551(dot)50205(at)enterprisedb(dot)com> <48EB95B7(dot)10604(at)frogthinker(dot)org>
<48EC7EB5(dot)5020001(at)enterprisedb(dot)com> <48ECAA8F(dot)3070306(at)frogthinker(dot)org>
<28137(dot)1223472191(at)sss(dot)pgh(dot)pa(dot)us> <48ECBBC2(dot)6060003(at)frogthinker(dot)org>
<29132(dot)1223475486(at)sss(dot)pgh(dot)pa(dot)us> <48EFA13C(dot)2060407(at)frogthinker(dot)org>
<490F804A(dot)60108(at)enterprisedb(dot)com> <490FB4B3(dot)908(at)frogthinker(dot)org>
<49106B10(dot)2090407(at)enterprisedb(dot)com> <4910DFC0(dot)3080301(at)frogthinker(dot)org>
<4914CD14(dot)2060608(at)frogthinker(dot)org> <4921C42A(dot)3030600(at)enterprisedb(dot)com>
<492221A3(dot)1060608(at)frogthinker(dot)org> <4922A798(dot)7050709(at)enterprisedb(dot)com>
<49232993(dot)1050801(at)enterprisedb(dot)com> <49243376(dot)2000404(at)frogthinker(dot)org>
<492543D5(dot)9050904(at)enterprisedb(dot)com> <492B377F(dot)4080602(at)frogthinker(dot)org>
<49344E22(dot)2000008(at)frogthinker(dot)org>

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

--
Emmanuel Cecchet
Aster Data Systems - Frontline data warehousing
Web: http://www.asterdata.com

Attachment Content-Type Size
patch-2pc-temp-table-8.4v5-withtests.zip application/octet-stream 9.6 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-12-16 22:43:32 Re: Another issue in default-values patch: defaults expanded too soon
Previous Message Bruce Momjian 2008-12-16 22:06:53 Re: [ADMIN] shared_buffers and shmmax