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=ji85qAfJbjEl+f3NMbwlyxA0suDMydIEuYM23ohh1AO820GkTg5C5Pw8IzCHzSmdkNZE0V0PSAHr7li+QjfojTc5+f9R5SLPKoIUobYL5xc4jFaMdcSmDnYLdc6IQSJu;
Message-ID: <48EB95B7.10604@frogthinker.org>
Date: Tue, 07 Oct 2008 13:00:39 -0400
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: pgsql-hackers@postgresql.org
Subject: Re: Transactions and temp tables
References: <48EA7B12.6050906@frogthinker.org>
	<48EB0551.50205@enterprisedb.com>
In-Reply-To: <48EB0551.50205@enterprisedb.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Heikki,

> The patch allows preparing any transaction that has dropped the temp 
> table, even if it wasn't created in the same transaction. Is that sane?
If you have a temp table created with an 'on commit delete rows' option 
in another transaction, it would be fine to drop it in another 
transaction. If the temp table was created without any on commit option, 
it could only cross prepare commit if it is empty and then it could be 
safely dropped in another transaction. That does not seem to insane for 
me if you need temp tables for a session.
> Also, even if the table is created and dropped in the same 
> transaction, a subsequent transaction that tries to create and drop 
> the table gets blocked on the lock. I suppose we could just say that 
> that's the way it works, but I'm afraid it will come as a nasty 
> surprise, making the feature a lot less useful.
I do not get that one, if the table is dropped in the transaction the 
lock is released. Why would another transaction be blocked when trying 
to create/drop another temp table?
When I run my test cases (see attached file in previous mail), I 
create/drop multiple times the same temp table in different transactions 
and I do not experience any blocking.
> The fixed-size array of temp table oids is an unnecessary limitation. 
> A list or hash table would be better.
You are right, I will fix that.
>> Let me know what you think of the patch and if it could be applied to 
>> 8.3 and 8.4?
> Not to 8.3. We only back-patch bug-fixes, and this isn't one.
Ok understood.

Thanks for your feedback and don't hesitate to enlighten me on the 
potential locking issue I did not understand.
Emmanuel

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