Question about tuple´s lock

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