Search Postgresql Archives

The Curious Case of the Table-Locking UPDATE Query

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello!
We have a huge POSTGRES 9.4 database in the production environment (several tables have more than 100.000.00 registers). Last two months we have had problems with CPU utilization. Debugging the locks (on pg_locks) we notice that sometimes simple UPDATE (by primary key) operation takes out ACCESS_EXCLUSIVE_LOCK mode over these huge tables so POSTGRES DB collapses and it generates excessive CPU consumption. My question is, How is it possible that UPDATE operation takes out ACCESS_EXCLUSIVE_LOCK mode?
More information, this system never manifests this behavior before and we don't make software changes on last 2 years

Attachment: Screenshot from 2021-07-05 12-14-22.png
Description: PNG image


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux