Re: Referential Integrity and SHARE locks

"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> Thus we have three types of write lock:
> 1. full row write lock
> as well as two mutually exclusive groups of columns:
> 2.a) PK cols
> 2.b) all columns apart from the PK cols

This appears to require that we add enough fields to row headers to
represent *three* locking transactions instead of the current one.
Given the amount of griping about row header overhead that normally
flows across this list, I can't see such a proposal getting accepted.

> This would be possible by using 2 additional tuple info bits to flag
> that the lock held was either HEAP_LOCKED_PK_ONLY or
> HEAP_LOCKED_NON_PK_COLS. When both lock types are held simultaneously we
> will replace xmax with a multitransaction id, where we hold only two
> transactionids at most - the first Xid is the holder of the PK cols
> lock, the second Xid is the holder of the non-PK cols lock.

You haven't thought that through: it fails to distinguish who holds
which lock (mxact membership is not ordered), and it doesn't scale to
more than two holders, and I don't think it works for combinations of
share and exclusive lock. Also, what happened to the third type of lock?

Implementation details aside, I'm a tad concerned about introducing
deadlock failures that did not happen before, in scenarios where
transactions touch the row multiple times and end up needing to
acquire one of these locks while already holding another.

regards, tom lane