From: | Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> |
---|---|
To: | Jeff Amiel <becauseimjeff(at)yahoo(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: table lock when where clause uses unique constraing instead of primary key. |
Date: | 2013-11-04 21:23:49 |
Message-ID: | 52781065.3030103@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 11/04/2013 01:16 PM, Jeff Amiel wrote:
>
>
>
>
>
> On Monday, November 4, 2013 2:56 PM, Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> wrote:
>
>> In the screenshot you posted what are the columns indicating, in
>> particular the third one?
>
>> Assuming the third column is pointing to the pid of the offending query
>> it is interesting that the other queries are coming from other IPs.
>> Almost as if the original query is bouncing off something. Is that possible?
>
> The third column is indeed the pid of the backend query that the query is 'blocked' by.
> Hmm...what means "bouncing off"?
>
Probably poor choice of words:). So then, what we are looking at is
other clients trying to update user_profile but not succeeding because
pid 4899 is blocking. At this point all I can see is that the offending
query is updating some fields the others are not; disabled and reset_code.
Is that always the case?
If so any thing in the code path that is different when those fields are
updated?
--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Janek Sendrowski | 2013-11-04 21:44:29 | Re: Suitable Index for my Table |
Previous Message | Rob Sargent | 2013-11-04 21:10:23 | Re: table lock when where clause uses unique constraing instead of primary key. |