[enhancement] add UI for blocked and blocking queries

[TanakritBenz]

Feature

Add a new tab that shows blocked and blocking queries.
Related issue: #183

Screenshot

Alert on index page:

The new tab:

[sanjayhallan]

+1 for this PR.

The issue has been closed - #183. But this PR is still open, any plans to merge this in?

Thanks

[jeremyhaile]

+1 for merging this in. We were just looking for something like this for pghero!

[TanakritBenz]

@ankane would you mind taking a look whenever you get a chance? :)

[Shuiei]

+1 🙏

[atanner27]

+1

[danielnc]

+1

[philmcc]

+1

[ankane]

Hey @TanakritBenz, thanks for the PR, and really sorry for the delay. I'm worried this will be too noisy. In most cases, it should only be an issue if queries are blocked for a significant amount of time and/or it's blocking a large number of queries.

Can you (and other on this thread) explain how you're using the blocked queries information, when it's problematic, and what instructions you would give users to resolve it?

[jagtesh]

@ankane A project I am working on can certainly leverage this. I do not think this is noisy at all, in fact it helps cut down on the noise and I'll explain how.

Right now, there's a significant cognitive overload - to look at all the slow queries and find the blocking ones manually. We've missed some blocking queries because of that in the past. This PR extracts this critical piece of information IMO, and brings it front and center.

Can you (and other on this thread) explain how you're using the blocked queries information, when it's problematic, and what instructions you would give users to resolve it?

For us, this often results in a deadlock. The project has 10 of 1000s of queries running at any given time, and finding blocked requires doing some analysis. Sure we can automate this, but the question right now is how can pghero help with this - and the answer is, by improving visibility.

For next steps, I would just leave a link to this: https://wiki.postgresql.org/wiki/Lock_Monitoring. The actions themselves will depend on each individual use-case.

[andyatkinson]

This does seem cool. Can it be hidden behind the extended flag so that users can opt in to it?

Can it be tuned in a way to address the noisiness?

Another thought was there is the "label" for an index that is unused. And perhaps in the live queries view, a label could be added like "[blocking]" as a way to expose this information perhaps.

@jagtesh Does it ever make sense to keep track of these blocking queries for later on analysis even if not in real time? I would imagine that could still be useful to dig through a list of some queries that blocked and go and check them out in the code.

[andyatkinson]

@jagtesh The screenshots look really awesome. Are you still using this in production? One question: when showing the lock type would it be possible to suggest an alternative less locky lock type or some other suggestion to avoid that lock in the future?

[ankane]

Cleaning up stale PRs (still have the same thoughts as #241 (comment)). For deadlocks, the server log should have the queries that caused it.

2022-05-20 15:17:40.563 PDT [88639] ERROR:  deadlock detected
2022-05-20 15:17:40.563 PDT [88639] DETAIL:  Process 88639 waits for ShareLock on transaction 146394; blocked by process 88663.
	Process 88663 waits for ShareLock on transaction 146393; blocked by process 88639.
	Process 88639: SELECT * FROM users WHERE id = 2 FOR UPDATE;
	Process 88663: SELECT * FROM users WHERE id = 1 FOR UPDATE;

[TanakritBenz]

Hi @ankane! Sorry for MIA, I didn't see your #241 (comment) and completely forgot about this PR. To be honest, I haven't had to deal with our DB much in the past few years as I'm more on the product side.

I believe our most common use case for this is: We use it as part of our drop/truncate process. The engineer would try locking the table in question and then check this view if the attempt is causing any new blocked queries. If it is, they would be rollback.

Edit: I chatted with some infra folks. Although they didn't say that this view is noisy, I didn't get a sense that this view is particularly useful for them. The reason is that it is real-time data only and can't show past data. If the lock wait timeout is low, say 3s, then the blocked queries would only show briefly. I think if someone can expand on this PR and make it able to show past data, say last 5 minutes, then it'd become more valuable to add.

[ankane]

Hey @TanakritBenz, big thanks for the update! The drop/truncate process is an interesting use case, but I (subjectively) think it probably doesn't justify an additional view. History/aggregate data is an interesting idea, but I'm not sure if the benefit will outweigh the complexity (of course, anyone is welcome to fork if they think it'll be useful for their application).