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

From: Jeff Amiel <becauseimjeff(at)yahoo(dot)com>
To: Adrian Klaver <adrian(dot)klaver(at)gmail(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:56:14
Message-ID: 1383602174.66198.YahooMailNeo@web161403.mail.bf1.yahoo.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general

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.
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....

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Kevin Grittner 2013-11-04 22:14:00 Re: Suitable Index for my Table
Previous Message Janek Sendrowski 2013-11-04 21:44:29 Re: Suitable Index for my Table