OOPS reports should log database locks
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Triaged
|
Low
|
Unassigned |
Bug Description
If Launchpad times out while executing an INSERT or UPDATE, it might be because it was unable to grab a lock. If this happens, we should reset the connection and grab the lock information, appending it to the OOPS report. Note that this information may well be out of date by the time we access it, but it should still help track down scripts that conflict with normal Launchpad operations.
SELECT
pg_locks.mode, pg_class.relname, pg_stat_
current_
pg_
FROM pg_locks, pg_database, pg_class, pg_namespace, pg_stat_activity
WHERE
pg_database.oid = pg_locks.database
AND pg_class.oid = pg_locks.relation
AND pg_namespace.oid = pg_class.
AND pg_stat_
AND pg_database.datname = current_database()
AND pg_class.
AND pg_namespace.
AND pg_locks.granted IS TRUE
AND pg_locks.mode like '%Exclusive%'
AND pg_stat_
< CURRENT_TIMESTAMP - interval '5 seconds';
tags: | added: oops-tools |
Changed in launchpad-foundations: | |
status: | New → Triaged |
importance: | Undecided → Low |
Changed in launchpad-foundations: | |
assignee: | nobody → Diogo Matsubara (matsubara) |
tags: |
added: oops-infrastructure removed: oops-tools |
Changed in launchpad: | |
assignee: | Diogo Matsubara (matsubara) → nobody |
See also the recent suggestion that we have postgresql tell us on the resultset some info about what went on.