Memory safety for Postgres extensions in C/C++

Summary

Postgres MemoryContext allocation combined with setjmp/longjmp error handling bypasses C++ destructors, leading to undefined behavior when C++ code runs inside a Postgres extension. C++ exceptions also bypass PG_CATCH, and an uncaught exception in a background worker aborts the process, forcing the postmaster to restart everything due to potential shared memory corruption. ClickHouse’s four Postgres extensions each used a different approach: pg_clickhouse replaced clickhouse-cpp with a new C library, pg_re2 scoped C++ to a single file, pg_chdb isolated libchdb in a helper executable, and pg_stat_ch uses a terminate handler. pg_chdb’s helper process runs outside the Postgres backend, so a libchdb crash fails only the calling operation without triggering cluster crash recovery. A long-term plan for pg_stat_ch moves its C++ dependencies into a helper executable, with PR #129 as the first step to isolate C++ from Postgres code.

Takeaways

1. 1

   Postgres’s setjmp/longjmp error handling can skip C++ destructors, leading to undefined behavior when automatic objects with nontrivial destructors exist.

2. 2

   pg_chdb isolates crashes by running libchdb in a separate helper executable via fork+exec, so a crash does not trigger Postgres cluster crash recovery.

3. 3

   pg_stat_ch uses a terminate handler that routes uncaught C++ exceptions through ereport(FATAL) instead of abort(), but this is a mitigation and cannot repair inconsistent shared memory.

FAQ