Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

github.com

Post reply on HN
Print view View original

91–100 of 756 posts

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#91

Post by ottavio »

oblio wrote: post #57
alex_duf wrote: post #40

Earlier quoted context omitted.

I think this shouldn't be taken too seriously, from what I understand it's an exploration of what's possible with today's LLMs. You're right to talk about the trend though, because what it shows is how the cost of re-writing well covered project has completely crashed, so that in itself is a learning.

The cost of surface level rewrites has crashed. Which will probably cover 80% of cases. Caveat emptor on which side your project falls.

I have no issues recognizing that I had memory-related problems in production (I program embedded systems in C).

But most of my issues were related to concurrency and data sanification, especially when the other end of communication fails with unexpected behavior. These bugs are nastier than memory.

So, I have pointers, and I am not afraid to use them.

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#92

Post by OtomotO »

rytill wrote: post #71
OtomotO wrote: post #48

Earlier quoted context omitted.

AI is an average coder. It was trained on all code the code that could be found. Not just code written by genius programmers like Carmack and Bellard. Given that it's average, I'd prefer a human coder above average :)

LLMs learn a distribution during pre-training, not only an average. Then, by giving them context or by post-training, you can make them sample non-average parts of the distribution they learned.

> Then, by giving them context or by post-training, you can make them sample non-average parts of the distribution they learned.

How do you derive that something is "below average" or "average" or "above average"?

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#93

Post by fragmede »

pknerd wrote: post #44

I am not trolling, but I have a simple question: Why? Why do I use this instead of the official build? What is the business case?

Because Rust is what's cool these days. Don't you wanna be cool? Also Rust has memory safety things that C++ doesn't have, so there's a class of bugs that can't happen in the Rust version. That doesn't mean the Rust version is 100% bug free, but just that it's not vulnerable to that class of bugs. So it's a good thing for security reasons if you're running a database server somewhere that attackers could get at it. There might be performance benefits down the road if they choose to focus on that.

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#94

Post by mechazawa »

queoahfh wrote: post #66
josefrichter wrote: post #47

Why so much negativity? I find these projects interesting for learning purposes and exploring new ways. What’s wrong with that?

I am concerned about the quality. Even a cursory skim of the code makes the code appear asinine. Unless the genius aspects of the code elude me. https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b... https://github.com/malisper/pgrust/blob/3646a73515a5e4ac7d0b...

Yeah same. The structure makes no real sense and when digging into the code it reads like I'm the first human to look at it.

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#95

Post by antihero »

piker wrote: post #58
josefrichter wrote: post #47

Why so much negativity? I find these projects interesting for learning purposes and exploring new ways. What’s wrong with that?

Because it’s uncomfortable to see decades of work copied so trivially.

But that's the thing, without the decades of work, it wouldn't BE trivial.

Everyone is standing on the shoulders of those which came before. If LLMs allow us to combine the incredible decades of effort and knowledge and experiences that's gone into building something as great as Postgres, and take that and combine the experience and philosophy that has led to the creation of a language that potentially provides tangible benefits, and for far less human time and effort that it would have otherwise taken...surely something that should be celebrated as absolutely incredible?

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#96

Post by martin-adams »

sshine wrote: post #14
gingersnap wrote: post #3

I 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 mostly the test, but the real world production scars Most extensive test suites are exactly production scars: every time you have a bug or a regression, you write a test that confirms correct behaviour. SQLite is a good example to bring up because its extensive closed-source tests are what’s often cited as being what keeps people from forking it. (Turso did it, though, but it takes a company to deliver some gua…

This feels like the image of the plane that returns from battle with bullet holes, and the engineer being asked to path up where the holes to make it stronger. Only to be told to patch where there weren't holes as those planes didn't make it home.

While not an exact fit of an analogy, those tests patch what was a problem with Postgres in the wild. What it doesn't cover are the things that worked in Postgres without tests, but may fail in port and go undetected.

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#97

Post by _s_a_m_ »

sshine wrote: post #14
gingersnap wrote: post #3

I 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 mostly the test, but the real world production scars Most extensive test suites are exactly production scars: every time you have a bug or a regression, you write a test that confirms correct behaviour. SQLite is a good example to bring up because its extensive closed-source tests are what’s often cited as being what keeps people from forking it. (Turso did it, though, but it takes a company to deliver some gua…

very naive. the runtime behavior of a rewrite should be significantly different in all kinds of unpredictable ways nobody see coming or might expect. It is a combination of language semantics, compiler behavior, operating system behavior, file system behavior, driver behavior, ..

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#98

Post by Lomlioto »

gingersnap wrote: post #3

I 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.

I hope you are not true at all.

Software like a Database should have an extensive test bench with concurrency tests, all corner cases etc.

I'm not here running the new version on production to tell the maintainer/devs that my 'production unit tests failed'.

What is this even for logic?

I mean there is balance when i write tests for my production software, but my software is used by me. If i would have a library, i would test everything.

And there was some blog post about another database system were they even virtualized the File access to test cases like when the disk controller stops working.

Re: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests

#100

Post by orphea »

eu-tech-tak wrote: post #72

How is the performance compared to regular PostgreSQL? I know it says it is not performance optimized yet, but if this succeeds, will it only bring more "memory safety" or is there a serious performance gain as well?

  will it only bring more "memory safety" or is there a serious performance gain as well?
The project will die in a couple of days or weeks. You're making a mistake if you're seriously consider using this in any capacity.
Post reply on HN