Re: Too many Row Exclusive Locks held for a long time

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: pavan95 <pavan(dot)postgresdba(at)gmail(dot)com>, pgsql-admin(at)postgresql(dot)org
Subject: Re: Too many Row Exclusive Locks held for a long time
Date: 2019-03-07 19:30:42
Message-ID: 518282bdc21dd4fc8bbd511a3f7ae69dd6404ac9.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

pavan95 wrote:
> I am facing an issue in one of the production servers.
>
> I have been observing there are many "Row Exclusive" locks occurring on a
> set of similar tables around 2000 locks at any given point of time. And
> then the application(Odoo) is being struck for a very long time.
>
> After we kill those Row Exclusive locks all the locks were released.
>
> Typically the below is the sample statement being run on database by the
> application users:
>
> SELECT id FROM abc WHERE id=5075 FOR UPDATE NOWAIT;
>
> So every time this issue occurs we need to go into server identify the "Row
> Exclusive Locks" process id's and kill them after which it works fine.
>
> So is there any permanent fix for this that we need to look upon?

ROW EXCLUSIVE is the lock taken on a table if a transaction wants to perform
INSERT, UPDATE or DELETE. It is a harmless lock.

If your application is getting stuck where such a lock is involved, that means:

1. A lock is held for a long time.

2. Something requests a conflicting lock, i.e. SHARE or higher.

Long transactions are evil not only because they hold locks,
but also because they prevent VACUUM from doing its job.

Taking high table locks (probably with an explicit LOCK statement) is something
hat should not be done regularly. For one, it makes autovacuum give up, which
can lead to table bloat.

Try to figure out what causes the high table lock (you should see it stuck
behind a ROW EXCLUSIVE lock or vice versa).

Try to fix the application so that it uses short transactions.

Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2019-03-07 19:40:51 Re: Upgrade 10.5->10.6 : db crash BUS ERROR (sig 10), reproducible
Previous Message Palle Girgensohn 2019-03-07 19:25:29 Re: Upgrade 10.5->10.6 : db crash BUS ERROR (sig 10), reproducible