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: manu@frogthinker.org
Skype: emmanuel_cecchet
