"Simon Riggs" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly