Re: Transactions and temp tables

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Emmanuel Cecchet <manu(at)frogthinker(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Transactions and temp tables
Date: 2008-11-20 11:02:45
Message-ID: 492543D5.9050904@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Emmanuel Cecchet wrote:
> I still quite did not get what the big deal was if an ON COMMIT DELETE
> ROWS temp table was created inside a transaction.

In case the transaction that created a temp table rolls back, the table
needs to be removed. Removing a temporary table belonging to another
backend is problematic; the local buffers in the original backend need
to be dropped, as well as the entry in the on commit actions list.

> 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?

If you release the lock early on a table that you drop, another
transactions would be free to access the table, even though it's about
to be dropped.

> I will try to find more time to review the patch tonight.

Thanks!

Thinking about this whole thing yet more, I wonder if we could have a
more holistic approach and make temporary tables work just like regular
ones. The problems we've identified this far are:

1. If the prepared transaction keeps the temp table locked, the backend
can't exit, because the shutdown hook tries to drop all temp tables.

2. When a prepared transaction that has deleted a temporary table
commits (or one that created one aborts), we need to drop all the local
buffers from the original backend's private buffer cache.

3. When a prepared transaction that has deleted a temporary table
commits (or one that created one aborts), we need to remove the
on-commit entry from the original backend's private list.

Is there more? I think we can solve all the above problems:

1. Modify RemoveTempRelations so that it doesn't block if it can't
immediately acquire lock on the to-be-removed object. That way the
original backend can exit even if a prepared transaction is holding a
lock on a temporary object.

To avoid conflict with a new backend that's assigned the same backendid,
divorce the temporary namespace naming from backendid so that the
temporary namespace name stays reserved for the prepared transaction.

2. Flush and drop all local buffers on temporary tables that have been
created or dropped in the transaction at PREPARE TRANSACTION already.

3. Add on-commit field to pg_class, and only keep a list of temporary
tables that have been accessed in the current transaction in
backend-private memory.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavan Deolasee 2008-11-20 11:06:20 Re: Hot Standby (commit fest version - v5)
Previous Message Heikki Linnakangas 2008-11-20 10:37:06 Re: pg_upgrade: How to deal with toast