PostgreSQL enforces SQL uniqueness constraints
using unique indexes, which are indexes that disallow
multiple entries with identical keys. An access method that supports this
feature sets pg_am.amcanunique true.
(At present, only b-tree supports it.)
Because of MVCC, it is always necessary to allow duplicate entries to
exist physically in an index: the entries might refer to successive
versions of a single logical row. The behavior we actually want to
enforce is that no MVCC snapshot could include two rows with equal
index keys. This breaks down into the following cases that must be
checked when inserting a new row into a unique index:
If a conflicting valid row has been deleted by the current transaction,
it's okay. (In particular, since an UPDATE always deletes the old row
version before inserting the new version, this will allow an UPDATE on
a row without changing the key.)
If a conflicting row has been inserted by an as-yet-uncommitted
transaction, the would-be inserter must wait to see if that transaction
commits. If it rolls back then there is no conflict. If it commits
without deleting the conflicting row again, there is a uniqueness
violation. (In practice we just wait for the other transaction to
end and then redo the visibility check in toto.)
Similarly, if a conflicting valid row has been deleted by an
as-yet-uncommitted transaction, the would-be inserter must wait
for that transaction to commit or abort, and then repeat the test.
We require the index access method to apply these tests itself, which
means that it must reach into the heap to check the commit status of
any row that is shown to have a duplicate key according to the index
contents. This is without a doubt ugly and non-modular, but it saves
redundant work: if we did a separate probe then the index lookup for
a conflicting row would be essentially repeated while finding the place to
insert the new row's index entry. What's more, there is no obvious way
to avoid race conditions unless the conflict check is an integral part
of insertion of the new index entry.
The main limitation of this scheme is that it has no convenient way
to support deferred uniqueness checks.
