From: | Augustin Amann <augustin(at)waw(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Update / Lock (and ShareLock) question |
Date: | 2008-07-11 14:23:36 |
Message-ID: | 48776CE8.10207@waw.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane a écrit :
> Augustin Amann <augustin(at)waw(dot)com> writes:
>
>> During lock, we could see things like this in log file:
>> Process 5556 waits for ShareLock on transaction 14910066; blocked by
>> process 4940.
>>
>
> What that really means is that the first process is waiting for a row
> lock that's held by the second one --- that is, it's trying to update a
> row that the second transaction has updated and not yet committed.
>
>
Ok. So it's normal ...
Thank you for your fast reply. Good to know that it's not a design
problem...
>> Why waiting update are not simply queued ?
>>
>
> Uh, that's exactly what's happening.
>
>
I understand. But a dead lock is for me, a situation that sould not
appear, event if the storage is slow ... I'm wrong ?
Here is the log:
2008-07-10 19:26:41 CEST UPDATE waiting pid=8028 db=xxxx_db
sess=48764626.1f5c
ERROR: deadlock detected
2008-07-10 19:26:41 CEST UPDATE waiting pid=8028 db=xxxx_db
sess=48764626.1f5c
DETAIL: Process 8028 waits for ShareLock on transaction 14836545;
blocked by pr
ocess 8124.
Process 8124 waits for ShareLock on transaction 14837154;
blocked by process 8028.
2008-07-10 19:26:41 CEST UPDATE waiting pid=8028 db=xxxx_db
sess=48764626.1f5c
STATEMENT: UPDATE yyyyy SET display=display+1 WHERE id='73' AND
hour='19' AND day='2008-07-10' ;
Look strange to me !
> regards, tom lane
>
>
Regards,
Augustin.
From | Date | Subject | |
---|---|---|---|
Next Message | Vivek Khera | 2008-07-11 14:44:36 | Re: view row-level locks |
Previous Message | Tom Lane | 2008-07-11 14:13:52 | Re: Update / Lock (and ShareLock) question |