Обсуждение: Question about tuple´s lock

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 Sia Trecho 08, lotes 245 / 255 / 265 || +55 (61) 3039-9700 71205-080 || Guará || Brasília, DF 0800-6020097 www.tecnisys.com.br

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!

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

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