Re: table lock when where clause uses unique constraing instead of primary key. - Mailing list pgsql-general

From Jeff Amiel
Subject Re: table lock when where clause uses unique constraing instead of primary key.
Date
Msg-id 1383602174.66198.YahooMailNeo@web161403.mail.bf1.yahoo.com
Whole thread Raw
In response to Re: table lock when where clause uses unique constraing instead of primary key.  (Adrian Klaver <adrian.klaver@gmail.com>)
Responses Re: table lock when where clause uses unique constraing instead of primary key.
List pgsql-general




On Monday, November 4, 2013 3:23 PM, Adrian Klaver <adrian.klaver@gmail.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.
Any thoughts as to the fact that this could be a full table_lock simply based on the use of username (non primary key -
butspecifically unique constraint) in the where clause?  I'm grasping I know.... 


pgsql-general by date:

Previous
From: "Janek Sendrowski"
Date:
Subject: Re: Suitable Index for my Table
Next
From: Kevin Grittner
Date:
Subject: Re: Suitable Index for my Table