Message-ID: <48EB0551.50205@enterprisedb.com>
Date: Tue, 07 Oct 2008 09:44:33 +0300
Organization: EnterpriseDB
User-Agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724)
MIME-Version: 1.0
To: Emmanuel Cecchet <manu@frogthinker.org>
CC: pgsql-hackers@postgresql.org
Subject: Re: Transactions and temp tables
References: <48EA7B12.6050906@frogthinker.org>
In-Reply-To: <48EA7B12.6050906@frogthinker.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

Emmanuel Cecchet wrote:
> Instead of relying on a boolean that tells if a temp table was accessed, 
> I keep a list of the Oid for the temp tables accessed in the transaction 
> and at prepare commit time, I check if the relations are still valid. I 
> also added a check to allow empty temp tables at prepare commit time 
> (this allows to use temp tables with 'on commit delete rows' options.
> 
> I am attaching the patch and the use cases I have been using to test it. 
> The test cases try to compile the various use cases that I have seen 
> reported on the list.

Thanks for looking into this.

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?

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.

The fixed-size array of temp table oids is an unnecessary limitation. A 
list or hash table would be better.

> 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.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com