Hi Heikki,
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?
If you have a temp table created with an 'on commit delete rows' option
in another transaction, it would be fine to drop it in another
transaction. If the temp table was created without any on commit option,
it could only cross prepare commit if it is empty and then it could be
safely dropped in another transaction. That does not seem to insane for
me if you need temp tables for a session.
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.
I do not get that one, if the table is dropped in the transaction the
lock is released. Why would another transaction be blocked when trying
to create/drop another temp table?
When I run my test cases (see attached file in previous mail), I
create/drop multiple times the same temp table in different transactions
and I do not experience any blocking.
The fixed-size array of temp table oids is an unnecessary limitation.
A list or hash table would be better.
You are right, I will fix that.
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.
Ok understood.
Thanks for your feedback and don't hesitate to enlighten me on the
potential locking issue I did not understand.
Emmanuel
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: [EMAIL PROTECTED]
Skype: emmanuel_cecchet
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
