@yawlabs/postgres-mcp 0.6.10 → 0.6.12

package/CHANGELOG.md

@@ -7,54 +7,37 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
-## [0.6.10] - 2026-05-16
-
-### Infrastructure
-- Republishes the 0.6.7-0.6.9 coverage additions, which never reached
-  npm. The `pg_top_queries orderBy=calls` numeric-vs-lexical ordering
-  test was removed after three round-trips trying to make it
-  environment-independent. pg_stat_statements on PG17/18 fingerprints
-  `SELECT 1 AS x_a` and `SELECT 2 AS x_b` to the same query id (column
-  aliases drop out of the jumble even though they're preserved in the
-  displayed text), so two markers with different aliases collapse to
-  one entry and the ordering assertion has nothing to compare. Local
-  WSL clusters differentiate; CI doesn't. The alias-shadowing trap at
-  `stats.ts:60-67` remains documented at the call site and the other
-  six coverage additions are unaffected.
-
-## [0.6.9] - 2026-05-16 [UNPUBLISHED]
-
-Tagged but never published to npm -- the pg_top_queries ordering test
-still failed in CI even after switching marker queries from cursor-
-wrapped handler calls to raw `runInternal`. Root cause was column-alias
-jumbling in pg_stat_statements; the test was removed in 0.6.10.
+## [0.6.12] - 2026-05-16
 
-## [0.6.8] - 2026-05-16 [UNPUBLISHED]
-
-Tagged but never published to npm -- the v0.6.8 attempt at the
-pg_top_queries test still depended on `pg_stat_statements.track_utility`
-being on, which the CI image's defaults don't guarantee. Shipped in 0.6.9.
-
-## [0.6.7] - 2026-05-16 [UNPUBLISHED]
+### Fixed
+- `pg_inspect_locks` now resolves `relation` for the common case of row-level
+  contention. Previously, `SELECT FOR UPDATE` + `UPDATE` row-level waits
+  queued on a `transactionid` lock with `pg_locks.relation = NULL`, so the
+  handler returned `relation: null` and gave the agent no hint as to which
+  table was contested. A fallback subquery now resolves the contested table
+  from the blocker's held write-intent relation locks (RowShareLock,
+  RowExclusiveLock, etc.), filtering out plain SELECT's AccessShareLock so
+  unrelated tables the blocker only read from don't show up. Closes #5.
 
-Tagged but never published to npm -- the initial coverage additions
-included an ordering test for pg_top_queries that failed in CI on a
-test-stability issue (not a code issue). The other six coverage
-additions shipped in 0.6.10.
+## [0.6.11] - 2026-05-16
 
+### Infrastructure
+- Tightened the `pg_inspect_locks` real-contention test: replaced the
+  500ms hardcoded sleep with a 5s polling loop on `pg_blocking_pids()`
+  (avoids flakes on slow CI hosts and wasted time on fast ones), and
+  moved the `waiterPromise` await into the `finally` block so an
+  assertion failure mid-test still drains the queued waiter query
+  rather than leaving a floating promise.
 
+## [0.6.10] - 2026-05-16
 
 ### Infrastructure
-- Closed seven coverage gaps surfaced by a coverage audit. No behavior
+- Closed six coverage gaps surfaced by a coverage audit. No behavior
   changes; each test pins a branch the existing suite exercised on only
   one side, or a structural property a regression could silently violate:
   - `pg_inspect_locks` real ACCESS EXCLUSIVE contention with two side
     clients. Covers the LATERAL `unnest(pg_blocking_pids(...))` and the
     per-(blocked, blocker) row shape the v0.6.6 description claims.
-  - `pg_top_queries` `orderBy: 'calls'` numeric (not lexical) ordering.
-    A 12-call query must rank above a 2-call query -- pins the
-    alias-shadowing fix where unqualified `calls` would resolve to the
-    text output alias and sort lexically (`"2" > "12"`).
   - `pg_table_bloat` `minDeadRatio` threshold filter, as a relative
     property (filtered rows are at or above the threshold; baseline rows
     below the threshold are absent from filtered). Order-independent.

package/dist/index.js

@@ -36391,7 +36391,35 @@ var adminTools = [
                      FROM pg_catalog.pg_class c
                      JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
                      WHERE c.oid = bl.relation)
-             ELSE NULL
+             ELSE (
+               -- transactionid / virtualxid waits have bl.relation = NULL
+               -- because the wait is on the blocker's xid, not on a relation.
+               -- The contested table is usually identifiable from the
+               -- blocker's held write-intent locks: SELECT FOR UPDATE takes
+               -- RowShareLock, UPDATE/INSERT/DELETE take RowExclusiveLock,
+               -- migrations take stronger modes. Filter out the AccessShare
+               -- locks (plain SELECT) the blocker also holds on every table
+               -- they read from -- those aren't the contention source. If
+               -- the blocker has touched multiple write-intent tables in
+               -- their transaction, this is a best-effort hint, not a
+               -- definitive answer; the blocked/blocking queries above let
+               -- the caller disambiguate.
+               SELECT n.nspname || '.' || c.relname
+               FROM pg_catalog.pg_locks blocker_locks
+               JOIN pg_catalog.pg_class c ON c.oid = blocker_locks.relation
+               JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace
+               WHERE blocker_locks.pid = blocking.pid
+                 AND blocker_locks.locktype = 'relation'
+                 AND blocker_locks.granted
+                 AND blocker_locks.mode IN (
+                   'RowShareLock', 'RowExclusiveLock', 'ShareLock',
+                   'ShareRowExclusiveLock', 'ShareUpdateExclusiveLock',
+                   'ExclusiveLock', 'AccessExclusiveLock'
+                 )
+                 AND n.nspname NOT IN ('pg_catalog', 'information_schema')
+               ORDER BY n.nspname, c.relname
+               LIMIT 1
+             )
            END AS relation,
            bl.locktype AS lock_type
          FROM pg_catalog.pg_locks bl
@@ -37550,7 +37578,7 @@ function compareVersions(a, b) {
 }
 
 // src/index.ts
-var version2 = true ? "0.6.10" : (await null).createRequire(import.meta.url)("../package.json").version;
+var version2 = true ? "0.6.12" : (await null).createRequire(import.meta.url)("../package.json").version;
 var subcommand = process.argv[2];
 if (subcommand === "version" || subcommand === "--version") {
   console.log(version2);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@yawlabs/postgres-mcp",
-  "version": "0.6.10",
+  "version": "0.6.12",
   "mcpName": "io.github.YawLabs/postgres-mcp",
   "description": "PostgreSQL MCP server - query, schema introspection, explain, and health checks for AI assistants",
   "license": "MIT",