Re: Blocking excessively in FOR UPDATE

From: Claudio Freire <klaussfreire(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Blocking excessively in FOR UPDATE
Date: 2011-11-03 19:29:02
Message-ID: CAGTBQpY+O4m9Tyqo=6En7+r-1qdMws5O_rk9MbEo-HRxAJsyMw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Thu, Nov 3, 2011 at 3:45 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Claudio Freire <klaussfreire(at)gmail(dot)com> writes:
>> But I cannot figure out which transaction it would be. There *are*, in
>> fact, connections in <idle in transaction> state, which makes me think
>> those would be the culprit. But for the life of me, I cannot make
>> sense of the pg_locks view, which shows all locks as granted:
>
> A block on a row would typically show up as one transaction waiting on
> another's XID.  Did you capture this *while* the query was blocked?

Yes

> Also, I'm suspicious that you may be using a view that filters out
> the relevant lock types --- that's obviously not a raw display of
> pg_locks.

It's pgadmin, which I usually use to monitor pg_stats_activity and
pg_locks in a "pretty" view.
pg_locks does not show the query, only the pid, so it's harder to spot.

Next time I find it blocking, I will check pg_locks directly and post
the output.

I did that once, and they were all granted. I didn't correlate with
other XIDs since I thought the "granted" column meant it wasn't
waiting. Is that wrong?

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Claudio Freire 2011-11-03 19:53:41 Re: Blocking excessively in FOR UPDATE
Previous Message Jay Levitt 2011-11-03 18:49:53 Re: Predicates not getting pushed into SQL function?