Unique and Primary Key Constraints

Primary key and unique constraints are supported for RLV store loads, inserts and updates, in a specific way.

Because the RLV store does not maintain secondary indexes, enforcement requires a separate unique value checking process. Furthermore, no exclusive table lock is taken for RLV table writes, so new row values can be inserted, updated or deleted and subsequently committed by other connections while the current connection performs its operations.

Although RLV modifications committed after a transaction snapshot are not visible to the current connection, before any new values can be committed, any values added or removed due to those modifications are considered during unique and primary key checking, to avoid constraint violation.

Unique and primary key value checking has two phases.
  1. The new values are checked against values in the RLV store for uniqueness. As values are inserted into the RLV store, each one is checked for uniqueness against committed and uncommitted values in the RLV store (a "first updater wins" methodology). Uncommitted deletes are not considered for unique checking unless they are part of the current transaction.
  2. The new values are checked against IQ main store values. Before inserting into the RLV store, each value is checked against the IQ main store index for uniqueness (excluding any deleted and updated IQ main store rows visible to the transaction in the RLV store).