Currently, lock_t is a union of table locks and record lock bitmaps. There can be multiple record lock bitmaps in a transaction. A record lock bitmap is specific to an index leaf page and a locking mode. It could be more efficient to use a single bitmap per page, with 4 bits per record heap number to represent all combinations of record and gap lock modes: {shared,exclusive,gap-read,gap-write}.

      There are two types of gap locks (covering the open range of keys from the preceding record to the anchor record). A gap-read lock (taken by UPDATE, DELETE, or a locking SELECT) prevents any INSERT to that range. A gap-write lock (LOCK_INSERT_INTENTION) is mutually exclusive with gap-read locks. An INSERT requires both a gap-write lock and an exclusive lock on the key that is being inserted. Any amount of gap-read or gap-write locks may be held on the same gap by different transactions, as long as there are not both gap-read and gap-write locks for the same gap.

      A transaction can wait for at most one record. It might be simplest to not create a separate bitmap for that, but instead store the attributes of the lock request in the trx_t object.


          Issue Links



              • Assignee:
                kevg Eugene Kosov
                marko Marko Mäkelä
              • Votes:
                1 Vote for this issue
                5 Start watching this issue


                • Created: