✅ Context leaks
Snapshots the MemoryContext tree before and after a query, then diffs it to surface contexts that were created but never freed.
Tools like Valgrind and AddressSanitizer are blind to PostgreSQL's internal memory model. They can't tell you that a palloc() went into the wrong MemoryContext, that a context leaked across a query boundary, or that shared memory sentinels were overwritten by a buggy extension.
pg_ext_memcheck runs inside the backend process, giving it full visibility into the MemoryContext tree and PostgreSQL's internal allocators.
| Bug class | Valgrind | ASan | pg_ext_memcheck |
|---|---|---|---|
| MemoryContext leak | ✗ | ✗ | ✓ |
| Wrong-context palloc | ✗ | ✗ | ✓ |
| Shmem boundary overrun | ± | ± | ✓ |
| DSM segment leak | ✗ | ✗ | ± (manual, cross-session only) |
| Use-after-reset bug | ✗ | ✗ | ✓ (BGWorker crash-isolated) |
| Context growth / bloat | ✗ | ✗ | ✓ |
| Heap use-after-free | ✓ | ✓ | ✗ |
✅ Context leaks
Snapshots the MemoryContext tree before and after a query, then diffs it to surface contexts that were created but never freed.
✅ Wrong-context allocations
Flags palloc() calls that land in long-lived contexts like TopMemoryContext or CacheMemoryContext when they should be query-local.
✅ Shmem overruns
Plants sentinel bytes around shared memory allocations and verifies their integrity after extension code runs.
✅ DSM lifecycle
Tracks DSM segment attach and detach calls to detect segments that are attached but never released.
✅ Use-after-reset / OOM simulation
Runs crash-inducing scenarios (use_after_reset, oom_simulation) in an isolated BGWorker process so SIGSEGV or OOM cannot kill the calling session. Crash is confirmed via BGWorker exit code.
✅ Context bloat
Measures monotonic growth across repeated invocations to detect slow, cumulative leaks.
The extension is in active development. See the Roadmap for a live view of what is done, in progress, and planned.