pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Emmanuel Cecchet <manu@frogthinker.org>
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Transactions and temp tables
Date: Wed, 03 Dec 2008 14:22:53 -0500
Message-ID: <4936DC8D.6070100@frogthinker.org> (raw)
In-Reply-To: <49364AFB.5060404@enterprisedb.com>
References: <48EA7B12.6050906@frogthinker.org>
	<48EB0551.50205@enterprisedb.com>
	<48EB95B7.10604@frogthinker.org>
	<48EC7EB5.5020001@enterprisedb.com>
	<48ECAA8F.3070306@frogthinker.org>
	<28137.1223472191@sss.pgh.pa.us>
	<48ECBBC2.6060003@frogthinker.org>
	<29132.1223475486@sss.pgh.pa.us>
	<48EFA13C.2060407@frogthinker.org>
	<490F804A.60108@enterprisedb.com>
	<490FB4B3.908@frogthinker.org>
	<49106B10.2090407@enterprisedb.com>
	<4910DFC0.3080301@frogthinker.org>
	<4914CD14.2060608@frogthinker.org>
	<4921C42A.3030600@enterprisedb.com>
	<492221A3.1060608@frogthinker.org>
	<4922A798.7050709@enterprisedb.com>
	<49232993.1050801@enterprisedb.com>
	<49243376.2000404@frogthinker.org>
	<492543D5.9050904@enterprisedb.com>
	<492B377F.4080602@frogthinker.org>
	<49344E22.2000008@frogthinker.org>
	<4934A4E0.8080208@frogthinker.org>
	<49364AFB.5060404@enterprisedb.com>

I would really like to have support for temp tables at least for the 
case where the table is created and dropped in the same transaction. But 
I guess that the other limitations on index, sequences and views would 
still hold, right?

manu

Heikki Linnakangas wrote:
> Emmanuel Cecchet wrote:
>> 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.
> A serial column uses a sequence behind the scenes.
>
> Hmm. Seems like we would need to treat sequences and indexes the same 
> as tables with ON COMMIT DELETE ROWS, i.e release the locks early and 
> don't error out.
>
> All in all, this is getting pretty messy. My patch felt a bit hackish 
> to begin with, and having to add special cases for sequences and 
> indexes would make it even more so. And what about temporary views? 
> I'm starting to feel that instead of special-casing temp relations, we 
> need to move into the opposite direction and make temp relations more 
> like regular relations. Unfortunately, that's not going to happen in 
> the 8.4 timeframe :-(. Let's try the other approach in 8.5.
>


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




view thread (36+ messages)  latest in thread

Message-ID: <4936DC8D.6070100@frogthinker.org>
Permalink:  ../4936DC8D.6070100@frogthinker.org/
Also on:    postgresql.org/message-id/4936DC8D.6070100@frogthinker.org

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: manu@frogthinker.org, heikki.linnakangas@enterprisedb.com, tgl@sss.pgh.pa.us
  Subject: Re: Transactions and temp tables
  In-Reply-To: <4936DC8D.6070100@frogthinker.org>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox