Encoutering deadlocks with Potlatch fequently #1990
Comments
|
Author: Andy Allan I do have an (unscreened for personal info) wireshark dump of the session, should that prove necessary. |
|
Author: tom[at]compton.nu I already have this reported by Richard in private email on my to do list for when I get home. No wireshark dump that you have will be any use however. |
|
Author: tom[at]compton.nu Sounds like it's a potlatch bug really though if it's trying to execute to putways on the same way at the same time. |
|
Author: Richard If it's two on the same way that certainly would be a bug, yes (assuming the user hasn't forced a retry after a seemingly hung connection) - Potlatch sets an .uploading flag on each way and won't reupload until that is reset again. That said, I don't see in the error message anything that would suggest it's doing that - though my ability to parse such messages is pretty minimal! |
|
Author: TomH I assume this is long since solved... |
Reporter: Andy Allan
[Submitted to the original trac issue database at 8.51pm, Monday, 22nd June 2009]
As discussed on IRC
An unusual error happened (in 'putway' 12340014.0). The server said: PGError: ERROR: deadlock detected
DETAIL: Process 6352 waits for ShareLock on transaction 48771985; blocked by process 7524.
Process 7524 waits for ShareLock on transaction 48771977; blocked by process 6352.
CONTEXT: SQL statement "SELECT 1 FROM ONLY "public"."changesets" x WHERE "id" OPERATOR(pg_catalog.=) $1 FOR SHARE OF x"
: INSERT INTO "ways" ("timestamp", "visible", "changeset_id", "id", "version") VALUES('2009-06-23 14:23:58.982187', 't', 1602463, 12340014, 19) RETURNING "id"
An unusual error happened (in 'putway' 12340095.0). The server said: PGError: ERROR: deadlock detected
DETAIL: Process 16002 waits for ExclusiveLock on tuple (71001,37) of relation 40989 of database 40962; blocked by process 7524.
Process 7524 waits for ShareLock on transaction 48771761; blocked by process 16002.
: UPDATE "changesets" SET "closed_at" = '2009-06-23 15:23:51.754944', "num_changes" = 37 WHERE "id" = 1602463
Note that the closed_at was 1 hour in the future when it occurred. This is in live mode, save mode is unconfirmed. What was going on was editing large TIGER freeways and deleting nodes from flyovers, and so alternating large putways on two ways with the occasional whichways as the screen is panned. I suspect this is just highlighting a timing problem due to their size.
The text was updated successfully, but these errors were encountered: