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=cx4Tmt5Uf1lBto0ECWQ6mYJK97dyAdtoJq9K1A20H/Hx6uZLZi2x71LHS2ATxByNAYLNjZXFBiq7eNULdNNE5DrKgSouvFeGl8V++S6Ian6YFiZby9Te075Z84VPS2n7;
Message-ID: <48EBCD41.7070409@frogthinker.org>
Date: Tue, 07 Oct 2008 16:57:37 -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> <48EB95B7.10604@frogthinker.org>
In-Reply-To: <48EB95B7.10604@frogthinker.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Heikki,

Here is a new version of the patch using a hash table as you suggested.
I also include the tests that I have added to the regression test suite 
to test the various scenarios.
All patches are based on Postgres 8.3.3, let me know if you want me to 
generate patch for 8.4.

Thanks in advance for your feedback,
Emmanuel


Emmanuel Cecchet wrote:
> 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