CONCEPT Cited by 1 source

Postgres hook¶

Definition¶

A Postgres hook is a function pointer inside Postgres core that starts out NULL and can be set by an extension to a function that runs before, after, or instead of the existing Postgres functionality at that hook point. When core Postgres reaches the hook call site it invokes the extension's function (if set) and passes through the result. Hooks are the public extensibility surface through which most non-trivial Postgres extensions modify behaviour without forking.

"Much of what Postgres extensions can do, they do using hooks. A hook is a function that runs before, after, or instead of existing Postgres functionality. Want to observe or replace the planner? There's a hook for that. Want to examine queries as they execute? There are three hooks for that. As of this writing, there are 55 hooks available to anyone writing Postgres extensions." (Source: sources/2026-04-21-planetscale-behind-the-scenes-how-database-traffic-control-works.)

Key hooks named in the wiki¶

Hook	What it gates	Wiki reference
`ExecutorRun`	query execution entry	Traffic Control admission check
`ProcessUtility`	DDL / utility statement execution	`pginsights` resource measurement
Planner hook	plan selection	Traffic Control cost estimation

Each hook wraps the original Postgres function so the extension sees the query "just before it executes and again just after it completes. Any time that has elapsed and any resources the worker process has consumed are directly attributable to that query."

Hook count as an extensibility signal¶

As of 2026-04, Postgres exposes 55 *_hook = NULL initialiser sites in mainline. The growth rate of this count over Postgres major versions is a rough proxy for how much the upstream project has invested in extension-without-fork as a development model. See patterns/postgres-extension-over-fork for the architectural consequence.

Hook chains and colocation¶

Multiple extensions can install on the same hook. The last one to load sees the chain tail; each is expected to call the previous chain link. This composition is cheap but not free — each link is an indirect call + measurement cost. patterns/hook-colocation-for-zero-overhead canonicalises the optimisation of merging new functionality into an existing extension that already holds the hook, rather than loading a second extension that installs the same hook.

Failure modes¶

Hooks can "add new failure modes" (a VLDB '25 paper referenced by Reynolds) because they run inside the Postgres worker process and share its address space. Misbehaving hooks can crash the worker, introduce query-plan divergence from upstream Postgres, or produce subtle semantic regressions visible only at scale.

Seen in¶

sources/2026-04-21-planetscale-behind-the-scenes-how-database-traffic-control-works — canonical wiki framing; named ExecutorRun, ProcessUtility, planner hook, and the 55-hook count. Traffic Control installs on ExecutorRun to gate query admission and on ProcessUtility to meter utility statements. The post also names the pginsights extension's hook-set as the platform Traffic Control colocates onto — a canonical instance of the colocation optimisation (see pattern page).