Thread: Question about tuple´s lock

Question about tuple´s lock

From
Carlos Alves
Date:

Hi!


I need some help to understand why a transaction wiht a row delete aquire a AccessExclusiveLock and a row update a ExclusiveLock.


To ilustrate, a made this scenario:

create table tblock

(

  id int primary key,

  value text

);

insert into tblock values (1, 'somevalue');


First start Transaction 1:

begin;

update tblock set value = 'othervalue' where id = 1;

-- keep this transaction opened


After, start Transaction 2:

begin;

update tblock set value = 'onemorevalue' where id = 1;

-- at this point, this transaction assumes a ExclusiveLock in the tuple;

-- keep this transaction opend


Then, start Transaction 3:

begin;

update tblock set value = 'lastofthevalues' where id = 1;

-- here i can see this transaction trying to aquire a AccessExclusiveLock in this tuple


So, my question is: why a delete row requires a AccessExclusiveLock in the tuple insteead of ExclusiveLock?


Bellow, a image of a query over pg_locks:


PostgreSQL version: 13

OS: Centos 7


Thanks in advance.

--
Carlos Alves
Especialista

Logo
Tecnisys

Sia Trecho 08, lotes 245 / 255 / 265 || +55 (61) 3039-9700
71205-080 || Guará || Brasília, DF 0800-6020097

www.tecnisys.com.br
Attachment

Re: Question about tuple´s lock

From
Carlos Alves
Date:

Em 24/10/2023 13:27, Carlos Alves escreveu:

Hi!


I need some help to understand why a transaction wiht a row delete aquire a AccessExclusiveLock and a row update a ExclusiveLock.


To ilustrate, a made this scenario:

create table tblock

(

  id int primary key,

  value text

);

insert into tblock values (1, 'somevalue');


First start Transaction 1:

begin;

update tblock set value = 'othervalue' where id = 1;

-- keep this transaction opened


After, start Transaction 2:

begin;

update tblock set value = 'onemorevalue' where id = 1;

-- at this point, this transaction assumes a ExclusiveLock in the tuple;

-- keep this transaction opend


Then, start Transaction 3:

begin;

update tblock set value = 'lastofthevalues' where id = 1;

-- here i can see this transaction trying to aquire a AccessExclusiveLock in this tuple


So, my question is: why a delete row requires a AccessExclusiveLock in the tuple insteead of ExclusiveLock?


Bellow, a image of a query over pg_locks:


PostgreSQL version: 13

OS: Centos 7


Thanks in advance.



I typed the last command wrong. Should be:


Transaction 3:

begin;

delete from tblock where id = 1;


Sorry!

Attachment

Re: Question about tuple´s lock

From
Tom Lane
Date:
Carlos Alves <carlos.alves@tecnisys.com.br> writes:
> I need some help to understand why a transaction wiht a row delete
> aquire a AccessExclusiveLock and a row update a ExclusiveLock. 

UPDATE can use the weaker lock type if it's not modifying any
column that is part of a unique index.  This is to allow concurrency
with foreign-key checks that might wish to grab a read-only (shared)
lock on such a tuple.

A DELETE, or an UPDATE that is modifying key columns, has to
conflict with foreign-key checks.

            regards, tom lane



Re: Question about tuple´s lock

From
Carlos Alves
Date:

Em 24/10/2023 17:31, Tom Lane escreveu:

Carlos Alves <carlos.alves@tecnisys.com.br> writes:
I need some help to understand why a transaction wiht a row delete
aquire a AccessExclusiveLock and a row update a ExclusiveLock.

UPDATE can use the weaker lock type if it's not modifying any
column that is part of a unique index.  This is to allow concurrency
with foreign-key checks that might wish to grab a read-only (shared)
lock on such a tuple.

A DELETE, or an UPDATE that is modifying key columns, has to
conflict with foreign-key checks.

            regards, tom lane


Tom, 

thank you very much for your straight to the point answer!

regards
Carlos Alves