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
