Re: The Curious Case of the Table-Locking UPDATE Query

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Emiliano Saenz <saenz(dot)emi(dot)jos(at)gmail(dot)com>, depesz(at)depesz(dot)com
Cc: pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: The Curious Case of the Table-Locking UPDATE Query
Date: 2021-07-08 19:54:06
Message-ID: f344f155-4bc8-69cf-21b5-96f9e812730d@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 7/8/21 12:09 PM, Emiliano Saenz wrote:
> I can see that you say but the database behavior is like the block is
> more general than one tuple.
> It is difficult to get a pg_lock snapshot to determine some access
> exclusive locks on some tables.
> Monitoring the database (by Zabbix), when this type of block appears
> (AccessExclusiveLock) the CPU consumption is extremely high due to it
> being over one main table for our business.
> The UPDATE operation has as target one tuple but the block can affect
> the complete table? Is it possible?
> Furthermore, monitoring other systems, it is strange that this type of
> block appears, except when we make a release and we edit the database
> structure, truncate tables, etc.

Per docs:

https://www.postgresql.org/docs/12/view-pg-locks.html

"The pid column can be joined to the pid column of the pg_stat_activity
view to get more information on the session holding or awaiting each
lock, for example

SELECT * FROM pg_locks pl LEFT JOIN pg_stat_activity psa
ON pl.pid = psa.pid;

Also, if you are using prepared transactions, the virtualtransaction
column can be joined to the transaction column of the pg_prepared_xacts
view to get more information on prepared transactions that hold locks.
(A prepared transaction can never be waiting for a lock, but it
continues to hold the locks it acquired while running.) For example:

SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx
ON pl.virtualtransaction = '-1/' || ppx.transaction;

"

So for the information in pg_locks.csv below, pid of 21187. Then you
will find out what is actually causing the lock.

>
> Best regards,
>
>
>
>
> On Thu, Jul 8, 2021 at 2:42 PM hubert depesz lubaczewski
> <depesz(at)depesz(dot)com <mailto:depesz(at)depesz(dot)com>> wrote:
>
> On Thu, Jul 08, 2021 at 02:35:33PM -0300, Emiliano Saenz wrote:
> > Attach the files.
>
> The pg_locks file doesn't show any access exclusive locks on any table?
>
> =$ awk -F, 'NR==1 || $13 == "AccessExclusiveLock"' pg_locks.csv
> Locktype,Database,Relation,Page,Tuple,Virtualxid,Transactionid,Classid,Objid,Objsubid,Virtualtransaction,Pid,Mode,Granted,Fastpath
> tuple,248043888,248044255,213071,39,NULL,NULL,NULL,NULL,NULL,198/814,21038,AccessExclusiveLock,f,f
> tuple,248043888,248044255,213071,39,NULL,NULL,NULL,NULL,NULL,34/90197,21187,AccessExclusiveLock,t,f
> tuple,248043888,248044255,213071,39,NULL,NULL,NULL,NULL,NULL,132/957,21007,AccessExclusiveLock,f,f
>
> As you can see all the AccessExclusive locks are on tuples (rows).
>
> Best regards,
>
> depesz
>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Browse pgsql-general by date

  From Date Subject
Next Message David G. Johnston 2021-07-08 20:02:20 Re: pg_dump's restore gives "operator does not exist: public.iprange = public.iprange" but copy paste works
Previous Message Christopher Causer 2021-07-08 19:50:36 pg_dump's restore gives "operator does not exist: public.iprange = public.iprange" but copy paste works