resource-ownerslisted

# resource-owners — automatic cleanup for reference-counted resources Every backend has a tree of ResourceOwner objects. When a scope exits (subtransaction ends, transaction commits, portal closes), its ResourceOwner releases all resources it holds. This is how PG can safely leak buffers, syscache refs, snapshots, plans across many code paths — the cleanup is centralized. Different from **MemoryContexts** — which manage `palloc`ed memory. Resowners manage **reference-counted or open resources** that need special release semantics (unpin a buffer, release a catcache ref, close a DSM handle). ## The file Single-file subsystem: - `src/backend/utils/resowner/resowner.c` (~1000 lines) — implementation. - `src/include/utils/resowner.h` (~150 lines) — the callback-based public API (PG 17+). - `src/backend/utils/resowner/README` — the definitive design doc; shorter than this skill. ## Two flavors — legacy and callback-based ### Legacy: per-resource-kind arrays (pre-PG-17) Historically, resowner.c had hard-coded arrays for each resource kind (buffer pins, catcache refs, plancache refs, tupledesc refs, etc.). Each kind had `Resource<Kind>OwnerRemember` and `Resource<Kind>OwnerForget`; on release, the resowner scanned each array and released. This required a code change in resowner.c whenever a new resource kind was added — problematic for extensions. ### PG 17+ callback-based API Extensions and core resource kinds can now register their own release callback: ```c static con