Message-ID: <490F804A.60108@enterprisedb.com>
Date: Tue, 04 Nov 2008 00:50:50 +0200
Organization: EnterpriseDB
User-Agent: Mozilla-Thunderbird 2.0.0.16 (X11/20080724)
MIME-Version: 1.0
To: Emmanuel Cecchet <manu@frogthinker.org>
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>
In-Reply-To: <48EFA13C.2060407@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:
> Here is the latest patch and the regression tests for the temp tables 
> and 2PC issue.

This fails:

postgres=# begin;
BEGIN
postgres=# CREATE TEMPORARY TABLE temp1 (id int4);
CREATE TABLE
postgres=# PREPARE TRANSACTION 'foo';
PREPARE TRANSACTION
postgres=# CREATE TEMPORARY TABLE temp2 (id int4);
ERROR:  cannot insert into frozen hashtable "accessed temp tables"

I don't understand the bookkeeping of accessed and prepared temp tables
in general. What's it for?

The comments on preparedTempRel says that it keeps track of "accessed
temporary relations that have been prepared commit but not committed
yet". That's never going to work as a backend-private hash table,
because there's no way to remove entries from it when the prepared
transaction is committed or rolled back from another backend.

What's the purpose of checking that a table is empty on prepare? I think
I'd feel more comfortable with the approach of only accepting PREPARE
TRANSACTIOn if the accessed temp tables have been created and destroyed
in the same transaction, to avoid possibly surprising behavior when a
temp table is kept locked by a prepared transaction and you try to drop
it later in the sesssion, but the patch allows more than that. I guess
accessing an existing ON COMMIT DELETE ROWS temp table would also be OK,
  but checking that there's no visible rows in the table doesn't achieve
that.

I don't think you can just ignore "prepared temp relations" in
findDependentObjects to avoid the lockup at backend exit. It's also used
for DROP CASCADE, for example.

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