I've an interesting error with deadlocks on a quite simple table:
Version: 8.1
Query: update last_modified set dataend=now() where type='list'
DB-Error : ERROR: deadlock detected
DETAIL: Process 10454 waits for ShareLock on transaction 1347632; blocked by
process 15920.
Mario Weilguni [EMAIL PROTECTED] writes:
Version: 8.1
Query: update last_modified set dataend=now() where type='list'
DB-Error : ERROR: deadlock detected
DETAIL: Process 10454 waits for ShareLock on transaction 1347632; blocked by
process 15920.
Process 15920 waits for
Am Dienstag, 13. Dezember 2005 16:35 schrieb Tom Lane:
Mario Weilguni [EMAIL PROTECTED] writes:
Version: 8.1
Query: update last_modified set dataend=now() where type='list'
DB-Error : ERROR: deadlock detected
DETAIL: Process 10454 waits for ShareLock on transaction
Mario Weilguni [EMAIL PROTECTED] writes:
Since the type field is PK, there cannot be 2 rows with type='list', I guess
the deadlock must have some different explanation.
Then the deadlock must involve rows in two different tables. What else
are you doing in the same transaction(s) as updating
Am Dienstag, 13. Dezember 2005 16:52 schrieb Tom Lane:
Mario Weilguni [EMAIL PROTECTED] writes:
Since the type field is PK, there cannot be 2 rows with type='list', I
guess the deadlock must have some different explanation.
Then the deadlock must involve rows in two different tables. What
Mario Weilguni [EMAIL PROTECTED] writes:
I guess two backends might have issued interleaved updates.
I think without logging this cannot be solved here.
Yeah, it's annoying that there is no convenient way to see the contents
of pg_locks at the instant of the deadlock. Knowing which tuple
On Tue, 2005-12-13 at 11:04 -0500, Tom Lane wrote:
Mario Weilguni [EMAIL PROTECTED] writes:
I guess two backends might have issued interleaved updates.
I think without logging this cannot be solved here.
Yeah, it's annoying that there is no convenient way to see the contents
of pg_locks
