Clarify semantics of locks wrt SELECT/READ

[beckermarc]

There is a common misunderstanding that pessimistic locking, prevents plain select queries without locks.

See also HANA docs https://help.sap.com/docs/SAP_HANA_PLATFORM/4fe29514fd584807ac9f2a04f6754767/20fcf24075191014a89e9dc7b8408b26.html

See also PostgreSQL docs
https://www.postgresql.org/docs/current/explicit-locking.html#LOCKING-ROWS

See also H2 docs
https://www.h2database.com/html/commands.html#select

[agoerler]

Maybe we should have a table

state	select without lock	select with shared lock	select with exclusive lock / update
not locked	passes -> not locked	passes -> shared lock	passes -> exclusive lock
shared lock	passes -> not locked	passes -> shared lock	passes -> exclusive lock
exclusive lock	passes -> not locked	passes -> exclusive lock	waits -> exclusive lock

[beckermarc]

Maybe we should have a table

Maybe, but I don't think your table is correct, is it?

• "shared lock" / "select with exclusive lock / update" should be "waits"
• "exclusive lock" / "select with shared lock" should be "waits"

[agoerler]

Maybe we should have a table

Maybe, but I don't think your table is correct, is it?

• "shared lock" / "select with exclusive lock / update" should be "waits"

Yes, you are right. A shared lock can be promoted to an exclusive lock. But I think only in the transaction where the lock was originally created, I think. Others will wait.

• "exclusive lock" / "select with shared lock" should be "waits"

Yes, you are right.

[johannes-vogel]

Should we also link the db documentation?

[beckermarc]

The db docs are also rather cryptic sometimes and not so clear in my opinion. Therefore not sure if that provides a lot of additional value. Do you think they would be helpful after taking a look at them?