This is pretty cool as background information, but if you've ever run into a situation where you're not sure why something is locking, this kind of theoretical

This is pretty cool as background information, but if you've ever run into a situation where you're not sure why something is locking, this kind of theoretical info isn't that helpful. If you want to know what queries to kill, and what's blocked on what, check out these two very helpful Postgresql wiki pages: - https://wiki.postgresql.org/wiki/Lock_Monitoring https://wiki.postgresql.org/wiki/Lock_Monitoring - https://wiki.postgresql.org/wiki/Lock_dependency_information https://wiki.postgresql.org/wiki/Lock_dependency_information The "Recursive view of blocking" on the second page has been extremely helpful to me. You don't ever want to need this query but if you do, it's great. You should follow the page's recommendation and set it up as a view you can use if shit ever hits the fan. ...although you may want to show all the locks each pid has acquired, instead of the summary the query gives as written, by modifying it to use array_to_string(locks_acquired, E'\n') instead of array_to_string(locks_acquired[1:5] || CASE WHEN array_upper(locks_acquired,1) > 5 THEN '... '||(array_upper(locks_acquired,1) - 5)::text||' more ...' END, E'\n ')