Message-ID: <518282bdc21dd4fc8bbd511a3f7ae69dd6404ac9.camel@cybertec.at>
Subject: Re: Too many Row Exclusive Locks held for a long time
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: pavan95 <pavan.postgresdba@gmail.com>, pgsql-admin@postgresql.org
Date: Thu, 07 Mar 2019 20:30:42 +0100
In-Reply-To: <1551969446954-0.post@n3.nabble.com>
References: <1551969446954-0.post@n3.nabble.com>
Organization: Cybertec
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

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