Search Postgresql Archives

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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/04/2013 01:16 PM, Jeff Amiel wrote:





On Monday, November 4, 2013 2:56 PM, Adrian Klaver <adrian.klaver@xxxxxxxxx> 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@xxxxxxxxx


--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux