`seams` is the new emdash
Postgres rewritten in Rust, now passing 100% of the Postgres regression tests
331–340 of 756 posts
Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests
#332I just want to quibble that the 100% Postgres regression tests do not test the threaded aspect of this project, and that is a pretty fundamental architecture change.
Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests
#333This is impressive - but is a license change, from the PostgresQL license [0] to AGPL [1]. I like the AGPL and think it's the best truly free open source license, but I worry if this is compatible. Ie, if this is rewritten from the original source, should the original apply? (Yes.) There has been a trend to rewrite open source software with a more restrictive license (like coretools in Rust). This looks considerably…
The Postgres license is already fully compatible with the AGPL. BSD/MIT is more permissive.
Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests
#334Earlier quoted context omitted.
How exactly are rewriting something the equivalent of being the taliban?
Because they are blowing up old monuments as part of an attempt to enforce a hardline but nonsensical purity on other people.
Except for the monument still being there, and being the main thing everyone uses still.
Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests
#335Earlier quoted context omitted.
A thread per connection is a almost always the correct decision for performance, but by choosing a process per connection, postgres is able to let you load whatever sketchy extensions you want. Worst case you crash the process, not the database. It would be nice if you could strike a balance so a segfaul in the extension only crashes a small percentage of connections, not the whole thing.
If it's a choice between performance and being able to "safely" run sketchy extensions, I'd rather have performance.
A mixture of threads and processes that can be used to match processors, disk I/O, and network interfaces.
A very long time ago, there was once a feature called "Data Blades" which tanked a commercial database vendor. A badly behaving blade could bring down the entire database. Most anyone who has been working on databases for a few decades remembers this and makes a point of either not introducing these sorts of features or making use of processes over threads.
I have not looked at the code referenced in the mentioned project, but thus far I haven't seen a model that could craft a complete SQL parser on its own.
There are a number of problems, and design decisions, that a developer decides on when writing a database that I don't see any current models… just because you have the ingredients does not mean that the stew is edible.
Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests
#336I don’t trust AI rewrites, definitely not in 2026 — possibly never.
Code is code. It either does the job or doesn't. If there is nothing that could convince you that AI generated code is trustworthy (for whatever definition of trust) then this is an article of faith, not a rational position.
Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests
#337Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests
#338Earlier quoted context omitted.
Some of this post reminds me of a story I heard long ago from someone who had worked at a HW/SW company. They’d transferred an engineer from the ASIC design team to the OS kernel team, though he’d never been on a software team before. After a while the manager called him in for the following conversation: Manager: You’re doing amazing work — zero bugs in production! I’d like you to mentor the other SWEs on how to get…
Funny story but in my experience hardware engineers produce some of the worst software of the industry. Of course there must be some hardware engineers out there who do hood software but generally what they build are disasters.
I bet it's being organized by project rather than product. Conway's law ensures such an org will create code around projects, not products, and that always ends horribly.
Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests
#339Earlier quoted context omitted.
For instance, the TypeScript rewrite in Go was done mostly by humans and took a year before it was released. That is how you rewrite software that people can trust.
AI is a great use for this kind of boring, rote translation where precision is important. Humans are quite bad at it and tend to make mistakes. In either case the focus should be on improving testing, not trying to manually verify if the translation was correct by eye.
With programs large enough tests aren't going to ever be enough. Formal verification might work, but then who checks the specification for bugs?
Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests
#340I start to see a lot of these re-writes that depend on tests to state that its working. But the things that make software like Postgres and SQLite reliable are not mostly the test, but the real world production scars. That's where the reliability comes from, years and years of running in production.
Not weighing in on this specific rewrite but tests are how you specify that your software works correctly. If a behavior isn’t covered by an automated test in some form you can’t assert that any given change doesn’t break it.
I think it is completely reasonable to use a preexisting unmodified test suite to state that something is working. The larger the project the more true this becomes. Real world production scars are documented and guarded against in the test suite otherwise those lessons get lost.
Also SQLite is legendary for its massive test suite and extensive fuzzing. They have 590x the amount of test code and scripts than normal code. Source: https://sqlite.org/testing.html