Opened 10 years ago

Closed 8 years ago

#1990 closed defect (fixed)

Encoutering deadlocks with Potlatch fequently

Reported by: Andy Allan Owned by: Tom Hughes
Priority: major Milestone:
Component: api Version:
Keywords: Cc: richard@…

Description

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.

Change History (5)

comment:1 Changed 10 years ago by Andy Allan

I do have an (unscreened for personal info) wireshark dump of the session, should that prove necessary.

comment:2 Changed 10 years ago by Tom Hughes

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.

comment:3 Changed 10 years ago by Tom Hughes

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.

comment:4 Changed 10 years ago by 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!

comment:5 Changed 8 years ago by Tom Hughes

Resolution: fixed
Status: newclosed

I assume this is long since solved...

Note: See TracTickets for help on using tickets.