Find long-running SQL

Mon, 01 Jan 0001 00:00:00 +0000

Captured on 2026-09-27 (UTC+08) on a local KingbaseES V008R006C009B0014 primary, database test, using ~/kbdiag built from Go source commit 93bf65d (static linux/amd64 binary). This is lab evidence, not production validation. PIDs, counts and timings belong to this capture only. A fault-injection script started select pg_sleep(3600);, a statement that only sleeps. It tests detection, not CPU or disk pressure.

kbdiag 2.0 has no slow-SQL threshold yet: a long statement is listed and sorted, but not a WARN on its own. It becomes a finding when it holds a transaction open too long (txn) or makes others wait for a lock (locks).

Investigate lock waits

Mon, 01 Jan 0001 00:00:00 +0000

Captured on 2026-09-27 (UTC+08) on a local KingbaseES V008R006C009B0014 primary, database test, using ~/kbdiag built from Go source commit 93bf65d (static linux/amd64 binary). This is lab evidence, not production validation. PIDs, counts and timings belong to this capture only. A fault-injection script opened a transaction that took an ACCESS EXCLUSIVE lock on a test table and then sat idle, and a second session tried to read the table.

1. Who is waiting?

~/kbdiag locks
echo EXIT_CODE=$?

locks WARN (KingbaseES V008R006C009B0014, primary, system@local, 2026-09-27T13:36:33+08:00)

[WARN] lock.waiting session 1048829 has waited 13s for AccessShareLock on public.kbdiag_inj_lock, blocked by 1048819
 verify: kbdiag session 1048819 # what the blocking session is doing

blockers: 1
 pid blocks holds
 1048819 1 public.kbdiag_inj_lock AccessExclusiveLock

waiting: 1
 pid object wants waited blocked by
 1048829 public.kbdiag_inj_lock AccessShareLock 13s 1048819
EXIT_CODE=1

Session 1048829 has waited 13 seconds for AccessShareLock on public.kbdiag_inj_lock; the direct blocker is 1048819. Waits over 10 seconds are a WARN (--lock-wait-warn changes this).
blockers comes first, because the first question is who is in the way. It shows 1048819 blocks one session and holds AccessExclusiveLock on the table. When one blocker holds up dozens of sessions, it is the top row.
waiting lists each waiting session, longest wait first. The wait is measured from the waiter’s last state change, so it can overstate the wait a little, never understate it.

2. What is the blocker doing?

Follow the verify line:

Troubleshooting scenarios on kbdiag

Find long-running SQL

Investigate lock waits

1. Who is waiting?

2. What is the blocker doing?