Live data from Hacker News

Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents

eterdb.com

21–22 of 22 posts

Re: Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents

#21
post #11

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.

Good 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)

Re: Show HN: EterDB, a Postgres fork that makes it easy to recover from incidents

#22
This is interesting, and I would like to know how it actually works, but I can’t understand the tech page. I tried.

Could you write that by hand? It would make it a lot easier to understand. I’d also recommend removing the various mentions to previous versions, or at least shifting them to footnotes. It’s confusing to be reading an implementation and then finding out later that it isn’t the approach that was taken.

Post reply on HN