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

Поиск
Список
Период
Сортировка
От Adrian Klaver
Тема Re: table lock when where clause uses unique constraing instead of primary key.
Дата
Msg-id 52781065.3030103@gmail.com
обсуждение исходный текст
Ответ на table lock when where clause uses unique constraing instead of primary key.  (Jeff Amiel <becauseimjeff@yahoo.com>)
Ответы Re: table lock when where clause uses unique constraing instead of primary key.  (Jeff Amiel <becauseimjeff@yahoo.com>)
Список pgsql-general
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


В списке pgsql-general по дате отправления:

Предыдущее
От: Rob Sargent
Дата:
Сообщение: Re: table lock when where clause uses unique constraing instead of primary key.
Следующее
От: "Janek Sendrowski"
Дата:
Сообщение: Re: Suitable Index for my Table