We hit a SIGSEGV where the backtrace was misleading: our fatal handler tried to print a stack trace and that trace capture sometimes crashed inside libunwind, so it looked like “unwinding is broken”.
What worked was building a deterministic postmortem harness (core dump + debug binary + symbols + matching source paths) inside Docker, then installing Codex in the same container so it could run GDB + rebuild/iterate in-place.
OpenAI Codex pivoted away from unstable backtraces and classified the crash via siginfo_t/ucontext_t. It turned out to be SEGV_PKUERR (Intel MPK/PKU) caused by a thread-local PKRU mismatch when some worker threads entered V8.
In short, Proton focuses on simplicity — it’s a single-instance engine powerful enough for most common streaming and analytics workflows.
Features like clustering, mutable streams, and S3-based stream storage/state checkpoints are part of the enterprise edition, while Proton keeps the core performance and streaming capabilities in an open-source form.
Dynamic Tables are interesting for declarative streaming. In the ClickHouse ecosystem, you might want to look at materialized views combined with streaming engines.
For real-time transformations, there are a few approaches:
- Native ClickHouse MaterializedViews with AggregatingMergeTree
- Stream processors that write to ClickHouse (Flink, Spark Streaming)
- Streaming SQL engines that can read/write ClickHouse
We've been working on streaming SQL at Proton (github.com/timeplus-io/proton) which handles similar use cases - continuous queries that maintain state and can write results back to ClickHouse. The key difference from Dynamic Tables is handling unbounded streams vs micro-batches.
What's your specific use case? Happy to discuss the tradeoffs.
We hit a SIGSEGV where the backtrace was misleading: our fatal handler tried to print a stack trace and that trace capture sometimes crashed inside libunwind, so it looked like “unwinding is broken”.
What worked was building a deterministic postmortem harness (core dump + debug binary + symbols + matching source paths) inside Docker, then installing Codex in the same container so it could run GDB + rebuild/iterate in-place.
OpenAI Codex pivoted away from unstable backtraces and classified the crash via siginfo_t/ucontext_t. It turned out to be SEGV_PKUERR (Intel MPK/PKU) caused by a thread-local PKRU mismatch when some worker threads entered V8.
PR with the patch: https://github.com/timeplus-io/proton/pull/1091