SHARED locks barging behaviour
| От | Arul Ajmani |
|---|---|
| Тема | SHARED locks barging behaviour |
| Дата | |
| Msg-id | CANxv=LFB9v10Ftt=yD7-RBSOYzCO8_s8VThf39KgF1ZDafYUCA@mail.gmail.com обсуждение исходный текст |
| Ответы |
Re: SHARED locks barging behaviour
|
| Список | pgsql-hackers |
I'm trying to better understand the following barging behaviour with SHARED locks.
Setup:
Then, performing the following operations in 3 different sessions, in order, we observe:
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:
Setup:
postgres=# create table t(a INT);
CREATE TABLE
postgres=# INSERT INTO t VALUES(1);
INSERT 0 1
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
Thanks
В списке pgsql-hackers по дате отправления: