PostgreSQL REPEATABLE READ serialization limits on concurrent updates

In PostgreSQL, the REPEATABLE READ isolation level utilizes Multiversion Concurrency Control (MVCC) to provide a consistent snapshot as of the start of the first query. While this implementation effectively prevents phantom reads—exceeding the standard SQL requirement—it introduces specific constraints regarding concurrent data modification.

When a transaction attempts to update a row that has been modified and committed by another concurrent transaction after the current transaction's snapshot began, the engine returns a 'could not serialize access' error (SQLSTATE 40001). This shifts the burden of conflict resolution to the application layer rather than relying on row-level waiting.

Under what specific scenarios does REPEATABLE READ fail to prevent write skew that the SERIALIZABLE level would otherwise catch? How does the behavior differ between a duplicate key error and a serialization error when evaluating unique index constraints under this isolation level?