ClickHouse explains why C++ can put PostgreSQL extensions at risk

ClickHouse has detailed how mixing C++ with PostgreSQL’s memory and error-handling systems can turn an extension failure into a wider server problem. Its account offers developers practical ways to reduce that risk, from keeping C++ away from PostgreSQL calls to isolating it in a helper process.

ClickHouse Watch analysis

What happened

ClickHouse’s 30 September engineering post describes four PostgreSQL extensions that bring C++ into a system written in C. PostgreSQL uses palloc and MemoryContext for memory management, and can handle errors with setjmp and longjmp. C++ destructors and exception handling do not fit neatly across that boundary: a PostgreSQL error jump can bypass C++ cleanup, while an uncaught C++ exception can abort a process.

The team outlines a different approach for each extension. It removed C++ from pgclickhouse by replacing a C++ client library with a C library; confined C++ in pgre2 to code that does not call PostgreSQL; and moved pgchdb’s C++ runtime into a separate helper executable. For pgstatch, it describes handling PostgreSQL and C++ exceptions together, while stressing that this is a mitigation, not a general guarantee against crashes. Read ClickHouse’s engineering post.

Why it matters

The boundary between two languages can become an operational fault line when their memory and error-handling rules differ. ClickHouse says a C++ failure in the wrong place can affect PostgreSQL processes beyond the extension itself. Its examples make the trade-offs concrete: remove the risky boundary, keep it contained, or move it into a separate process where failures are less likely to trigger cluster-wide recovery.

Our read

This is a useful engineering explainer, not a claim that one pattern makes every extension safe. The strongest lesson is to design the boundary deliberately and treat process isolation as a meaningful option, not an afterthought. If you maintain a PostgreSQL extension that calls C++ code, check where errors can cross between the two runtimes and what happens when cleanup fails.

What to watch

• Whether ClickHouse publishes further details on the C++ isolation work planned for pgstatch.
• How extension maintainers handle PostgreSQL error jumps across C++ objects and destructors.
• Whether independent testing or documentation supports the approaches in other extension designs.

Discussion spark: For PostgreSQL extensions that need C++, should maintainers favour keeping C++ away from PostgreSQL calls, or isolating it in a separate process?

not affiliated with or endorsed by ClickHouse