From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Emmanuel Cecchet <manu(at)frogthinker(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Transactions and temp tables |
Date: | 2008-12-03 09:01:47 |
Message-ID: | 49364AFB.5060404@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Emmanuel Cecchet wrote:
> There is a problem with temp tables with on delete rows that are created
> inside a transaction.
> Take the 2pc_on_delete_rows_transaction.sql test case and change the
> creation statement, instead of
> create temp table foo(x int) on commit delete rows;
> try
> create temp table foo(x serial primary key) on commit delete rows;
>
> The test will fail. It looks like the onCommit field is not properly
> updated when serial or primary key is used in that context. I did not
> figure out why.
A serial column uses a sequence behind the scenes.
Hmm. Seems like we would need to treat sequences and indexes the same as
tables with ON COMMIT DELETE ROWS, i.e release the locks early and don't
error out.
All in all, this is getting pretty messy. My patch felt a bit hackish to
begin with, and having to add special cases for sequences and indexes
would make it even more so. And what about temporary views? I'm starting
to feel that instead of special-casing temp relations, we need to move
into the opposite direction and make temp relations more like regular
relations. Unfortunately, that's not going to happen in the 8.4
timeframe :-(. Let's try the other approach in 8.5.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Ibrar Ahmed | 2008-12-03 09:29:06 | Re: pg_stop_backup wait bug fix |
Previous Message | Heikki Linnakangas | 2008-12-03 08:46:00 | Re: Transactions and temp tables |