From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
Cc: | postgres performance list <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Blocking excessively in FOR UPDATE |
Date: | 2011-11-03 18:45:36 |
Message-ID: | 6734.1320345936@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Claudio Freire <klaussfreire(at)gmail(dot)com> writes:
> The same query, without FOR UPDATE, takes just 68 milliseconds.
> With the FOR UPDATE, it takes like half a minute or more to finish.
> Now, I understand the for update part may be blocking on some other
> transaction, and it's probably the case.
Yeah, that's what I'd guess.
> 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?
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Jay Levitt | 2011-11-03 18:49:53 | Re: Predicates not getting pushed into SQL function? |
Previous Message | Tom Lane | 2011-11-03 18:41:16 | Re: Predicates not getting pushed into SQL function? |