DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=frogthinker.org;
	h=Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User;
	b=rfYMZPlzwx2jT0Qp2gjMFwGk/x6qPE3duveZJPL4b6/qByyR5KEweUq/4J/STwCC/o6jbmDYonDFloiqme1CMunMOmobHD0luL80/2TzyRihX2qHN9JxCnBi6o3vFlhr;
Message-ID: <49243376.2000404@frogthinker.org>
Date: Wed, 19 Nov 2008 10:40:38 -0500
From: Emmanuel Cecchet <manu@frogthinker.org>
Organization: Frog Thinker
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
CC: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@postgresql.org
Subject: Re: Transactions and temp tables
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>
In-Reply-To: <49232993.1050801@enterprisedb.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Heikki,

I will try to make more tests.
I still quite did not get what the big deal was if an ON COMMIT DELETE 
ROWS temp table was created inside a transaction.
Why the new checks you are doing in lock.c would not work with dropped 
temp tables? Could it be possible to drop the lock as soon as the temp 
table is dropped inside a transaction?

I will try to find more time to review the patch tonight.

Best,
Emmanuel

> Heikki Linnakangas wrote:
>> Somehow this feels pretty baroque, though. Perhaps a better approach 
>> would be to add a new AtPrepare_OnCommitActions function to 
>> tablecmds.c, that gets called before AtPrepare_Locks. It would scan 
>> through the on_commits list, and release all locks for the 
>> "PREPARE-safe" temp tables, and throw the error if necessary. I'll 
>> try that next.
>
> Here's what I ended up with. I morphed the on commit action 
> registration into tracking of all temporary relations.
>
> This only allows access to ON COMMIT DELETE ROWS temp tables. 
> Accessing other temporary tables, and creating or dropping tables in 
> the transaction is still forbidden.
>
> It took me a couple of iterations to handle toast tables and indexes 
> correctly. More testing would be appreciated with more complex cases 
> like VACUUM FULL, subtransactions etc.
>


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