Pimp My IDE / garage dispatch
Back to garage
September 30, 2026 | PostgreSQL / native extensions / failure containment

Your extension shares the blast radius.

A native PostgreSQL extension can call straight into the server. That speed also puts allocator rules, C++ cleanup, shared memory, and process failure on the same shop floor.

Draw the language boundary and the process boundary separately. Test what crosses each one.

The shared library is inside the machine.

PostgreSQL loads user-written C functions from shared libraries on demand. The server keeps a loaded object in memory for later calls in the same session. PostgreSQL's C extension guide says these functions follow the same coding conventions as internal functions.[2]

That is the appeal. An extension can use server data types, memory contexts, hooks, shared memory, and the Server Programming Interface. It is also the risk. A native extension is not a remote service with a network boundary.

Language safety and crash isolation answer different questions.

PostgreSQL and C++ unwind by different rules.

ClickHouse engineer Philip Dube describes the mismatch from four PostgreSQL extensions. PostgreSQL ties palloc allocations to memory contexts and uses setjmp and longjmp for error handling. C++ uses destructors and exceptions. A PostgreSQL jump can skip C++ cleanup. An uncaught C++ exception can abort the process.[1]

PostgreSQL's own guide tells extension authors to use palloc and pfree instead of malloc and free. It also requires a module magic block so the server can reject obvious incompatibilities, such as a library built for another PostgreSQL major version.[3]

One team used four boundary shapes.

ClickHouse removed C++ from pg_clickhouse. It kept C++ inside a narrow wrapper for pg_re2, with C++ allocation and exception handling kept away from PostgreSQL C calls. For pg_chdb, it moved the C++ dependency into a helper executable and exchanged data across a smaller protocol.[1]

pg_stat_ch currently keeps C++ in a background worker with handlers for C++ and PostgreSQL failures. The post warns that this is a mitigation, not a general isolation guarantee. A failed cleanup or damaged shared memory can still make the postmaster treat termination as a crash.[1]

Rust reduces one class of mistakes.

The pgrx project gives Rust extensions managed PostgreSQL versions, schema generation, type conversion, memory-context helpers, and cross-version tests. Its README says Rust panics can become PostgreSQL errors instead of process aborts. It also exposes direct unsafe access to PostgreSQL internals through pg_sys.[4]

Rust can make ownership and null handling easier to inspect. It does not turn in-process code into an isolated process. The extension still needs a pinned server version, failure tests, and review of every unsafe or foreign-function boundary.

Write the crash contract before the wrapper.

  1. List which side owns every allocation and release.
  2. State which calls may raise a PostgreSQL error or a language exception.
  3. Keep destructors away from paths that PostgreSQL can jump across.
  4. Record whether the code runs in a backend, managed worker, or helper process.
  5. Kill the extension path on purpose and record what restarts, disconnects, or survives.
  6. Pin the PostgreSQL major version, compiler, extension revision, and test command.
Interactive makeover / extension crash bulkhead

Crash Bulkhead

Traditional purpose replaced: a flat extension checklist. Better version: shift the code through four placements, see the boundary move, and generate a test-plan shell that keeps missing evidence visible.

Place the dependency

Choose an architecture. The display explains the cited boundary shape. It does not calculate real production risk.

Execution placement
Test-plan sections
Test plan draft0 of 4 sections selected
Boundary teaching model

PostgreSQL and dependency

PostgreSQL sideC entry point, PostgreSQL allocator, PostgreSQL error route
Narrow
seam
Dependency sideC++ allocation, destructors, exceptions, no PostgreSQL calls
Placement 2 / 4: C++ island

Keep both error systems off the same stack frame.

A narrow wrapper can separate allocation and exception rules. It does not create process isolation.

This control compares architecture shapes described in the sources. Selecting every section means the test-plan structure is ready. It does not mean the extension survived a crash or that the cluster is safe.

Sources read

Source log and evidence boundary
  1. Philip Dube, "Memory safety for Postgres extensions in C/C++", ClickHouse Engineering, September 30, 2026. The post describes memory and error-handling conflicts plus four boundary choices used in ClickHouse PostgreSQL extensions. Its worker discussion states the limits of its mitigation.
  2. PostgreSQL 18 documentation, "Extensions". It states that independently developed extensions can function like built-in features.
  3. PostgreSQL 18 documentation, "C-Language Functions". It documents dynamic loading, module magic, the version-1 calling convention, memory allocation rules, server APIs, and C++ guidance.
  4. pgrx repository, inspected at commit fc91c63ebad1. Its README documents supported PostgreSQL versions, test commands, panic handling, memory-context helpers, and direct unsafe access through pg_sys.
  5. Hacker News discussion 49909090, read September 30, 2026. It led to the ClickHouse post. It is not used to verify extension behavior.

Evidence boundary: The ClickHouse post supports its authors' account of their extensions and mitigations. PostgreSQL documentation supports extension loading and API rules. The pgrx repository supports its public interface claims. This pass did not build, load, fuzz, or crash any extension.