Hi Heikki,
I will try to make more tests.
I still quite did not get what the big deal was if an ON COMMIT DELETE
ROWS temp table was created inside a transaction.
Why the new checks you are doing in lock.c would not work with dropped
temp tables? Could it be possible to drop the lock as soon as the temp
table is dropped inside a transaction?
I will try to find more time to review the patch tonight.
Best,
Emmanuel
Heikki Linnakangas wrote:
Somehow this feels pretty baroque, though. Perhaps a better approach
would be to add a new AtPrepare_OnCommitActions function to
tablecmds.c, that gets called before AtPrepare_Locks. It would scan
through the on_commits list, and release all locks for the
"PREPARE-safe" temp tables, and throw the error if necessary. I'll
try that next.
Here's what I ended up with. I morphed the on commit action
registration into tracking of all temporary relations.
This only allows access to ON COMMIT DELETE ROWS temp tables.
Accessing other temporary tables, and creating or dropping tables in
the transaction is still forbidden.
It took me a couple of iterations to handle toast tables and indexes
correctly. More testing would be appreciated with more complex cases
like VACUUM FULL, subtransactions etc.
--
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
