Tom Lane a écrit :
> Augustin Amann <augustin@waw.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.