Database Running Queries Monitoring Block for Svelte

Edit SESSIONS at the top of the file: each entry has a pid, user, database, state (active, idle-in-tx or waiting), the seconds the statement or transaction has run at AS_OF_SECONDS, the wait event, the lock holder in blockedBy (0 for none) and the statement as an array of lines. In your app, fill it from pg_stat_activity joined with pg_blocking_pids() on the server and pass the rows in. The header, the lock chain and the bar lengths are all derived from these fields.

A session that waits for a lock carries the pid of the session that holds it. The side cell states the chain in a sentence ("4821 waits for 4812, which has been idle in a transaction for 9 minutes") and a button selects that blocker. If a filter hides the blocker the filter returns to All first, so the row you land on is always visible. A session that is not waiting never shows the button, but its space stays reserved so nothing moves.

It shows only the sessions in one state, and the list keeps its height so the side cell does not jump. Every state has at least one session in the demo, so the list never empties. The status line says how many sessions are showing.

The sessions, durations and statements are typed examples and the product is made up; nothing connects to a database. Copy statement uses the real clipboard and says if the browser refuses. Nothing can be terminated or cancelled here: in your app, wire a cancel action to your own server behind a confirmation.

Yes. State is a word under each row, the bar fill is solid, hatched or outlined, a waiting row has a lock glyph, and the timeout tick has a caption under the list. Each row is a radio with a full spoken description, so arrow keys and a screen reader both work.

The rows keep their two lines (pid, statement and duration over the state and bar), the side cell stacks under the list, and the filter wraps under the header text.