On Sun, Sep 07, 2003 at 11:24:42PM -0400, Tom Lane wrote:
> No. We handle that case by waiting for the transaction that's locked
> the row to commit or abort. (Waiting for a transaction is done by
> having every transaction take out exclusive lock on its xact ID when it
> starts; then would-be waiters try to take share lock on the xact ID,
> causing them to block till the exclusive lock is released.)
This is interesting in the nested transactions case. Suppose a
transaction takes a lock on a tuple. If another transaction tries to do
the same, it has to wait for the previous transaction to finish. That's
pretty clear and simple.
Now, if a subtransaction has got a lock on some tuple, and another
transaction tree tries to grab the lock on that tuple, it should have to
wait for the entire transaction tree to finish. But what if the
subtransaction that got the lock aborts? Maybe the waiter could awake
at that point.
I invented a "CommitContext", that is supposed to hold things that
should be kept in memory if a subtransaction commits, and discarded if
it aborts (think async notifies, smgr pending deletes). The list of
things has to be kept until the transaction tree is finished, but can be
discarded in a single operation if any subtransaction aborts. Maybe
some similar thing can be done with locks?
--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"El conflicto es el camino real hacia la union"
