9 comments

[ 3.3 ms ] story [ 28.3 ms ] thread
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_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  ')
This is a great tip. There are definitely a lot of times I've had to look this up in the middle of the night after getting paged.
Totally parsed the headline incorrectly and thought it was about a bug in Postgres that caused explorer.exe to freeze.
So I'm not as segfaulted as my self-check feature has reported.