I'm trying to better understand the following barging behaviour with SHARED locks.
Setup:
postgres=# create table t(a INT);
CREATE TABLE
postgres=# INSERT INTO t VALUES(1);
INSERT 0 1
Then, performing the following operations in 3 different sessions, in order, we observe:
| Session 1 | Session 2 | Session 3 |
BEGIN;
BEGIN
postgres=*# SELECT * FROM t WHERE a = 1 FOR SHARE;
a
---
1
(1 row) | | |
| postgres=# BEGIN;
BEGIN
postgres=*# SELECT * FROM t WHERE a = 1 FOR UPDATE;
* --- waits | |
| | BEGIN;
BEGIN
postgres=*# SELECT * FROM t WHERE a = 1 FOR SHARE;
a
---
1
(1 row)
* -- returns immediately |
Given there is a transaction waiting to acquire a
FOR UPDATE lock, I was surprised to see the second
FOR SHARE transaction return immediately instead of waiting. I have two questions:
1) Could this barging behaviour potentially starve out the transaction waiting to acquire the FOR UPDATE lock, if there is a continuous queue of transactions that acquire a FOR SHARE lock briefly?
2) Assuming this is by design, I couldn't find (in code) where this explicit policy choice is made. I was looking around LockAcquireExtended, but it seems like the decision is made above this layer. Could someone more familiar with this code point me at the right place?
Thanks