Message-ID: <49106B10.2090407@enterprisedb.com>
Date: Tue, 04 Nov 2008 10:32:32 -0500
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>
	<490F804A.60108@enterprisedb.com> <490FB4B3.908@frogthinker.org>
In-Reply-To: <490FB4B3.908@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:
>> 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,
> Yes, I was trying to allow also ON COMMIT DROP and ON COMMIT DELETE ROW. 
> An empty temp table at PREPARE time would be similar to an ON COMMIT 
> DELETE ROW table.

I think you'll want to check explicitly that the table is defined with 
ON COMMIT DELETE ROWS, instead of checking that it's empty.

>>  but checking that there's no visible rows in the table doesn't achieve
>> that.
> If the relation exist but contains no row, is it possible that the table 
> is not empty? What would I need to do to ensure that the table is empty?

Yeah, thanks to MVCC, it's possible that the table looks empty to the 
transaction being prepared, using SnapshotNow, but there's some tuples 
that are still visible to other transactions. For example:

CREATE TEMPORARY TABLE foo (id int4);
INSERT INTO foo VALUES (1);
begin;
DELETE FROM foo;
PREPARE TRANSACTION 'foo'; -- doesn't error, because the table is empty, 
according to SnapshotNow
SELECT * FROM foo; -- Still shows the one row, because the deleting 
transaction hasn't committed yet.

>> 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.
> Do you mean that it will break the DROP CASCADE behavior in general, or 
> that would break the behavior for master/child temp tables?

For temp tables, I suppose.

The hack in findDependentObjects still isn't enough, anyway. If you have 
a prepared transaction that created a temp table, the database doesn't 
shut down:

$ bin/pg_ctl -D data start
server starting
$ LOG:  database system was shut down at 2008-11-04 10:27:27 EST
LOG:  autovacuum launcher started
LOG:  database system is ready to accept connections

$ bin/psql postgres -c "begin; CREATE TEMPORARY TABLE temp (id integer); 
PREPARE TRANSACTION 'foo';"
PREPARE TRANSACTION
hlinnaka@heikkilaptop:~/pgsql.fsmfork$ bin/pg_ctl -D data stop
LOG:  received smart shutdown request
LOG:  autovacuum launcher shutting down
waiting for server to shut 
down............................................................... failed
pg_ctl: server does not shut down


> By the way, 
> does Postgres support child temp tables?

Yes.

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