Thread: 13.2.2. Repeatable Read Isolation Level #

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/16/transaction-iso.html
Description:

'UPDATE, DELETE, MERGE, SELECT FOR UPDATE, and SELECT FOR SHARE commands
behave the same as SELECT in terms of searching for target rows: they will
only find target rows that were committed as of the transaction start time.
However, such a target row might have already been updated (or deleted or
locked) by another concurrent transaction by the time it is found. In this
case, the repeatable read transaction will wait for the first updating
transaction to commit or roll back (if it is still in progress). If the
first updater rolls back, then its effects are negated and the repeatable
read transaction can proceed with updating the originally found row. But if
the first updater commits (and actually updated or deleted the row, not just
locked it) then the repeatable read transaction will be rolled back with the
message'

What behavior does the INSERT command exhibit?

On Saturday, July 13, 2024, PG Doc comments form <noreply@postgresql.org> wrote:

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/16/transaction-iso.html
Description:

'UPDATE, DELETE, MERGE, SELECT FOR UPDATE, and SELECT FOR SHARE commands
behave the same as SELECT in terms of searching for target rows:

What behavior does the INSERT command exhibit?