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.
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.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com