[wfaithfull]

Part of 0.9.0 (#103, "resource governance"; DESIGN.md §13). Records §14 item 52, marked "Decided (coordinator, pending owner review)".

An administrator can now bound what sessions ask for, without taking per-session tuning away from ordinary roles.

SIGHUP limits, applied at use. A call uses the lower of the session's setting and the limit. -1 means no limit; 0 means the same.

Limit	Bounds
warren.threads_limit	warren.threads
warren.compute_memory_limit	warren.max_compute_memory
warren.cache_memory_limit	warren.max_cache_memory
warren.build_memory_limit	warren.max_build_memory
warren.walk_paths_limit	warren.max_walk_paths

When a limit is the lower value, the error names the limit. The SQLSTATEs are the existing ones (53400 and 54000).

A cap on compute threads across the cluster. warren.cluster_threads_limit defaults to -1 (no cap). The docs suggest setting it to the server's core count. It first defaulted to the core count, but in CI concurrent calls then waited for threads until they hit statement_timeout, so it is now opt-in.

• The count of threads in use is held in the activity table in shared memory. The table's format moves to 2.
• A call runs with whichever threads are free. When none is free it waits on its latch and stays cancellable; the wait event is WarrenComputeThreads.
• Threads are given back when the pool drops, or at backend exit.
• The cap is not enforced where the shared table does not exist (PG 15/16 not preloaded). Each backend logs that once.

No SQL surface change. Schema drift reports none against 0.8.0.

Tests.

• Pure #[test]s for the clamp and grant arithmetic.
• #[pg_test]s for each limit at its use site, and for the pool's grant, its nesting and a cancelled wait.
• New test/compute_threads.py, run in CI. Four backends at threads = 4 use about 3.7 cores without a cap and about 1.0 with a cap of 1.
• The worker's local runs: pgrx pg16 845/845 and pg18 846/846; test/run.py 66/66 on PG 18 and on PG 16 preloaded.

Merge order. This branch waits until #123 (release 0.8.0) is merged. It then needs main merged in, with the "0.9.0 — in development" CHANGELOG heading unified.

Owner questions:

• The cap is now off by default. Should it be on by default in a later release?
• Add a compute_threads column to warren.backends()? That would be a schema change in 0.9.0.
• Waiting has no queue, so a backend can wait a long time under constant load. Is a fair queue wanted?
• Can rds_superuser set these parameters through a parameter group? This needs checking on a real instance.

---

Generated by Claude Code

[wfaithfull]

Generators + SQL harness (PG 16) failed in the pooler soak on f9dc3c0, with one client stopped by RuntimeError("SET statement_timeout = '120s': canceling statement due to user request"). Everything else in the job passed: the SQL suite with and without the preload, the concurrent refresh, compute threads, and crash recovery.

This looks like a race in the soak's chaos thread, not something this PR changed. Chaos picks a transaction-pool backend that is active in a warren. call from pg_stat_activity, then calls pg_cancel_backend(pid) (test/harness/pooler_soak/workload.py). If the call finishes in between, the cancel lands on whatever that backend runs next. Here that was another client's session setup (test/harness/session.py's SESSION_SETTINGS), which the client treats as fatal. The same job passed on this PR's previous head (ea2c6bc), which had the same soak and the same warren.backends() code. The merge from main added only additive changes from #135.

I'll re-run the failed job once when the run finishes. If it fails again I'll treat it as real. Either way, the soak needs a fix in its own PR: make the cancel conditional on the same call still running, or have a client retry a 57014 on its setup statements.

---

Generated by Claude Code