From: Tom Lane <tgl@sss.pgh.pa.us>
To: Claudio Freire <klaussfreire@gmail.com>
Cc: postgres performance list <pgsql-performance@postgresql.org>
Subject: Re: Blocking excessively in FOR UPDATE
Date: Thu, 03 Nov 2011 19:45:46 -0400
Message-ID: <19908.1320363946@sss.pgh.pa.us> (raw)
In-Reply-To: <CAGTBQpYK6-ycWr0WXRwz39Bv30sCbDe68CC3MbhUp9-jwu_V=g@mail.gmail.com>
References: <CAGTBQpY7zd9h+xv4Gvh0+-G1UgiWg1zd7zUsXPDFvQoGa4JScA@mail.gmail.com>
<6734.1320345936@sss.pgh.pa.us>
<CAGTBQpY+O4m9Tyqo=6En7+r-1qdMws5O_rk9MbEo-HRxAJsyMw@mail.gmail.com>
<CAGTBQpYK6-ycWr0WXRwz39Bv30sCbDe68CC3MbhUp9-jwu_V=g@mail.gmail.com>
Claudio Freire <klaussfreire@gmail.com> writes:
> On Thu, Nov 3, 2011 at 4:29 PM, Claudio Freire <klaussfreire@gmail.com> wrote:
>> Next time I find it blocking, I will check pg_locks directly and post
>> the output.
> Here it is, two instances of the query, while blocked:
Hmm ... definitely seems that you're not blocked on a FOR UPDATE tuple
lock. If you were, there'd be an ungranted ShareLock on a transactionid
in there.
It seems possible that you're blocked on an LWLock, which would not show
in pg_locks. But before pursuing that idea, probably first you should
back up and confirm whether the process is actually waiting, or running,
or just really slow due to CPU contention. It might be useful to see
what strace has to say about it.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, klaussfreire@gmail.com
Subject: Re: Blocking excessively in FOR UPDATE
In-Reply-To: <19908.1320363946@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox