Hi Heikki,
> Emmanuel Cecchet wrote:
>> As I have not found yet an elegant solution to deal with the DROP
>> CASCADE issue, here is a simpler patch that handles temp tables that
>> are dropped at commit time. This is a good first step and we will try
>> to elaborate further to support ON COMMIT DELETE ROWS.
>
> The problem with stopping the postmaster seems to still be there..
>
> All the problems are centered around locking. We need to address that
> and decide what is sane locking behavior wrt. temp tables and 2PC.
>
> First, there's the case where a temp table is created and dropped in
> the same transaction. It seems perfectly sane to me to simply drop all
> locks on the dropped table at PREPARE TRANSACTION. Does anyone see a
> problem with that? If not, we might as well do that for all tables,
> not just temporary ones. It seems just as safe for non-temporary tables.
This seems good to me. Any access to the table after PREPARE TRANSACTION
but before COMMIT on that backend would return a relation not found
which is what we expect. For a regular table, I don't know if that
makes a difference if the prepared transaction rollbacks?
> Secondly, there's the case of accessing a ON COMMIT DELETE ROWS table.
> There too, could we simply drop the locks at PREPARE TRANSACTION? I
> can't immediately see anything wrong with that.
As there is no data anyway, I don't think the locks are going to change
anything. But in the most recent stripped-down version of the patch, on
delete rows is no more supported, I only allow on commit drop. I did not
find the flag to see if a temp table was created with the on delete rows
option.
Do you want me to look at the locking code or will you have time to do
it? Hints will be welcome if you want me to do it.
Thanks,
Emmanuel
--
Emmanuel Cecchet
FTO @ Frog Thinker
Open Source Development & Consulting
--
Web: http://www.frogthinker.org
email: manu@frogthinker.org
Skype: emmanuel_cecchet
