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=WDwqludmaLYEOStxDvGyUWJvz5AtLUAnm63rrIPeBYmDn8lLmkKGzjMyg6rg4+AomXIanWR/chHNVz+yTBvTVPlzveycqIyNn+gW0tvcRQOxWbIsyCYhcmm4KggujYUa;
Message-ID: <492221A3.1060608@frogthinker.org>
Date: Mon, 17 Nov 2008 21:00:03 -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>
In-Reply-To: <4921C42A.3030600@enterprisedb.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Heikki,
> Emmanuel Cecchet wrote:
>> As I have not found yet an elegant solution to deal with the DROP 
>> CASCADE issue, here is a simpler patch that handles temp tables that 
>> are dropped at commit time. This is a good first step and we will try 
>> to elaborate further to support ON COMMIT DELETE ROWS.
>
> The problem with stopping the postmaster seems to still be there..
>
> All the problems are centered around locking. We need to address that 
> and decide what is sane locking behavior wrt. temp tables and 2PC.
>
> First, there's the case where a temp table is created and dropped in 
> the same transaction. It seems perfectly sane to me to simply drop all 
> locks on the dropped table at PREPARE TRANSACTION. Does anyone see a 
> problem with that? If not, we might as well do that for all tables, 
> not just temporary ones. It seems just as safe for non-temporary tables.
This seems good to me. Any access to the table after PREPARE TRANSACTION 
but before COMMIT on that backend would return a relation not found 
which is what we expect. For  a regular table, I don't know if that 
makes a difference if the prepared transaction rollbacks?
> Secondly, there's the case of accessing a ON COMMIT DELETE ROWS table. 
> There too, could we simply drop the locks at PREPARE TRANSACTION? I 
> can't immediately see anything wrong with that.
As there is no data anyway, I don't think the locks are going to change 
anything. But in the most recent stripped-down version of the patch, on 
delete rows is no more supported, I only allow on commit drop. I did not 
find the flag to see if a temp table was created with the on delete rows 
option.

Do you want me to look at the locking code or will you have time to do 
it? Hints will be welcome if you want me to do it.

Thanks,
Emmanuel

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