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 22:51:27 |
Message-ID: | 527824EF.80600@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 11/04/2013 01:56 PM, Jeff Amiel wrote:
>
>
>
>
>
> On Monday, November 4, 2013 3:23 PM, Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> wrote:
>
>
>> 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?
>
> We have scenarios where exact same query is in play in all instances.
Which query is that?
And what scenario are you talking about, blocking query or something else?
> Any thoughts as to the fact that this could be a full table_lock simply based on the use of username (non primary key - but specifically unique constraint) in the where clause? I'm grasping I know....
What makes you think the username condition is the problem?
>
>
--
Adrian Klaver
adrian(dot)klaver(at)gmail(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Ben Chobot | 2013-11-04 23:48:30 | Re: 9.1.9 -> 9.1.10 causing corruption |
Previous Message | Martijn van Oosterhout | 2013-11-04 22:30:25 | Re: Suitable Index for my Table |