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
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 |