Keep temp tables from eating session memory
A temporary table is not a lightweight scratchpad. It is buffered in per-session memory that is never shared and never reclaimed until the session ends, it is invisible to autovacuum, and each one writes rows into the shared catalog.
Problem
What you're actually looking at
The symptom as it shows up on a real server.
Temporary tables are cached in temp_buffers, a private allocation per session rather than part of shared_buffers. That allocation grows on demand up to the limit and is not released while the session lives, so under a connection pool — where sessions are long-lived by design — the cost accumulates per connection rather than per query.
A Meridian reporting job builds intermediate results in temporary tables. Run once by hand it is unremarkable. Running on every request through a pooler that keeps fifty connections warm, each of those sessions quietly grows its own private buffer set and holds it, and the resident memory of the database climbs with no query to blame.
In plain English
A temporary table looks like a cheap scratchpad, and for one query it is. What makes it different from an ordinary table is where it is kept: ordinary tables share one big cache that every session can use, while a temporary table is cached in a private area belonging to just that session. That private area grows as the session needs it and is not handed back until the session disconnects. On a laptop that is invisible, because the session ends a second later. Behind a connection pool it is not, because pooled sessions are deliberately kept alive for hours — so the memory belongs to fifty long-lived connections instead of one short one. Two smaller details compound it: automatic cleanup never touches these tables, and every one you create writes rows into the shared catalogue that all sessions read.
Full runbook for this incident
- The full identify checklist — the exact signals that tell you it's this incident
- Every diagnostic query; PostgreSQL 18 output is attached only to the steps we captured
- The resolution path and the pitfalls that make it worse
- Mitigation steps to stop it recurring, plus a verify-you're-done query
More in this category
Other Server memory runbooks
Neighbouring incidents that share the same diagnostic surface.