Seemingly trivial Bug/Archive updates/inserts timeout
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
Critical
|
Unassigned |
Bug Description
We have seem intermittent, and quite sporadic, timeouts doing what should be very simple update or insert operations.
eg
Time Reps Database id Statement
1. 10171.0 1 SQL-main-master
INSERT INTO BugMessage (bugwatch, OWNER, INDEX, message, bug, remote_comment_id)
VALUES (NONE, $INT ... $INT, NONE) RETURNING BugMessage.id
UPDATE Bug SET date_last_
UPDATE Bug
SET heat=calculate_
WHERE Bug.id = $INT
INSERT INTO
Karma ("action", datecreated, person, sourcepackagename, distribution, product)
VALUES (%s, CURRENT_TIMESTAMP AT TIME ZONE 'UTC', %s, %s, %s, %s)
RETURNING Karma.id
The suspicion is that locks being held are blocking things, most probably by scripts, many of which exhibit very naughty behaviour in this area.
More diagnosis is needed to establish what is locked at the time of these sorts of occurrence and what initiated the locks.
tags: | added: timeout |
summary: |
- Seemingly trivial updates/inserts timeout + Seemingly trivial Bug updates/inserts timeout |
description: | updated |
description: | updated |
summary: |
- Seemingly trivial Bug updates/inserts timeout + Seemingly trivial Bug/Archive updates/inserts timeout |
Changed in launchpad: | |
status: | Triaged → Fix Released |
This will be fixed by PostgreSQL 9.3's KEY SHARE locks, even if we don't fix the scripts to use more sensible transaction lengths.