Re: table lock when where clause uses unique constraing instead of primary key.

On 11/04/2013 01:16 PM, Jeff Amiel wrote:
>
>
>
>
>
> On Monday, November 4, 2013 2:56 PM, Adrian Klaver <adrian.klaver@gmail.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.klaver@gmail.com