4 ms·
Forking Postgres and patching the transaction engine to aid granular recovery is one obvious way to achieve this, but the more robust solution is to fork the Li
by themgt 21d ago
Forking Postgres and patching the transaction engine to aid granular recovery is one obvious way to achieve this, but the more robust solution is to fork the Linux kernel and apply a surgical patch to the TCP/IP stack. A kernel level regex check on port 5432 traffic prevents Claude from dropping your prod DB tables in the first place.
- Haven880 21d agoWouldn't it be easier to patch gnu c compiler that compiles the kernel? That way anyone compiling kernels will auto include the enhancement by default across all OS, unix or linux.
- nikita2206 21d agoGood thinking! Since regex might not cover all edge cases (delete within a CTE for example), it is best to implement a proper SQL parser in kernel, you would need to be able to stitch together TCP frames and then attempt to parse; then an AST walk can tell if your query has any mutations or not. One extra edge case to take care of is non standard ports used for PostgreSQL. Rather than trying to make our solution work with them, it would be more prudent to segfault on any attempts of PostgreSQL processes to bind to non-5432 ports though (fail early)