Tom Lane a écrit :
Augustin Amann <[EMAIL PROTECTED]> 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.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
