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

231–240 of 756 posts

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

#231

Post by richie_adler »

dxdm wrote: post #112
satvikpendem wrote: post #8

We had one for SQLite (which is SQL-ite btw, not SQ-Lite which doesn't make any sense) via Turso, no wonder we see the same for Postgres. Personally I do want to see libraries be in as much memory safe languages as possible.

How do you know it's not SQL-lite with the single L serving a double role? Common pronunciations allow you to stay perfectly ambiguous about where the L goes, which aligns quite well with the name as spelled. If you do it right, nobody can tell if you're saying sequel-ite or sequel-lite or seque-lite on the one hand, or S-Q-L-ite or S-Q-L-lite or S-Q-lite on the other. AFAIK there is no official word on how the name…

Richard Hipp says he doesn't care how anybody pronunces it. That said, he pronounces it "S-Q-L-ite".

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

#232

Post by josefrichter »

byzantinegene wrote: post #146
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?

can you enlighten me, what exactly do you learn from asking a llm to do a rewrite?

No, I can’t. The way you frame your question tells me you’re not seeking enlightenment.

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

#233

Post by nativeit »

lukasco wrote: post #207
sshine wrote: post #14

Earlier quoted context omitted.

> 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…

So many comments here talking about the downsides. The only reason to do a rewrite is because there are massive upsides. Maybe the implicit point is that the upside (memory safety must be the biggest), isn't worth the downside (lots of bugs to be figured out before you trust it).

I find a lot of HN discussions quickly turn into thought experiments and philosophical debates that largely forget the original topic. For the most part, I find this idiosyncrasy charming and entertaining, but it does frequently result in forests being missed for the trees.

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

#234

Post by danudey »

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…

sqlite is the pathological case though; it has ~590 times more SLOC in the test suite than in the actual sqlite project.

https://sqlite.org/testing.html

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

#235

Post by danudey »

martin-adams wrote: post #96
sshine wrote: post #14

Earlier quoted context omitted.

> 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 t…

I don't necessarily disagree, but two other points to consider:

1. Every test that is written is another use case that wasn't tested before. 100% test coverage is often impractical, but the more tests you have the more of the code you can be confident about.

2. Every test you add is another regression that can't happen in the future; if you test the index rebuilding code and validate the output then you know that you aren't going to make a change that breaks the index rebuilding code. If you have a legitimate change you update the tests, but if you're not expecting the change then you know there's a bug somewhere.

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

#236

Post by malisper »

iigijshaba wrote: post #211
malisper wrote: post #160

Earlier quoted context omitted.

I'm not sure what you mean? The rust code you're showing mimics the Postgres code: https://github.com/postgres/postgres/blob/2e6578292a9184dcaa... The boolean being returned is the return value of the function. It's not used to return an error.

Now that I have taken a closer look, the code looks significantly better than it seemed at first glance, though there are still peculiarities, and some drawbacks. An unfortunate aspect is that the code has become a bit more bloated in some regards due to usage of Result, instead of an implicit elog() macro and similar. Passing Result around, in some ways as an alternative to an unwinding exception, is cleaner in some…

> The rewrite also could have simpler code in some cases

The Rust code is a literal translation of the Postgres code which returns the value at the end instead of an early return.

> I see a lot of MemoryContext

MemoryContext in C is used for multiple reasons: 1) performance 2) keeping track of how much memory has been allocated and where and 3) preventing memory leaks.

Reasons 1 and 2 are still relevant for Rust. The challenge is in C memory contexts are stored in a global variable. Global variables don't work well with the rust borrow checker so I opted for passing memory contexts as function arguments instead.

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

#237

Post by derdi »

w4der wrote: post #90
bob1029 wrote: post #52

Earlier quoted context omitted.

> Software of this kind of complexity has all kinds of behavior that has never been broken This space of things is astronomically larger than the space of things expressly covered by any test suite. "Program testing can be used to show the presence of bugs, but never to show their absence." -Edsger W. Dijkstra

I've also seen situations where a customer reports a bug, the fix breaks some regression, and the updated behavior to work around the fix breaking the regressions turns into an undocumented feature.

How do you break a regression? A regression is breakage. Are you one of the people who use "regression" to mean "regression test"? Did Codex learn this from you? I hate it.

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

#238

Post by Apaec »

alirezaxdehghan wrote: post #157
piker wrote: post #58

Earlier quoted context omitted.

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

Imagine the feelings of a dude who used to code in assembly and then some punk writes in c++ and uses gcc... decades of work wasted.

That is a completely different thing than LLM generated code.

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

#239

Post by satvikpendem »

dxdm wrote: post #112
satvikpendem wrote: post #8

We had one for SQLite (which is SQL-ite btw, not SQ-Lite which doesn't make any sense) via Turso, no wonder we see the same for Postgres. Personally I do want to see libraries be in as much memory safe languages as possible.

How do you know it's not SQL-lite with the single L serving a double role? Common pronunciations allow you to stay perfectly ambiguous about where the L goes, which aligns quite well with the name as spelled. If you do it right, nobody can tell if you're saying sequel-ite or sequel-lite or seque-lite on the one hand, or S-Q-L-ite or S-Q-L-lite or S-Q-lite on the other. AFAIK there is no official word on how the name…

Because the creator himself said it's an -ite suffix similar to minerals like bauxite, not -lite.

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

#240

Post by dxdm »

satvikpendem wrote: post #239
dxdm wrote: post #112

Earlier quoted context omitted.

How do you know it's not SQL-lite with the single L serving a double role? Common pronunciations allow you to stay perfectly ambiguous about where the L goes, which aligns quite well with the name as spelled. If you do it right, nobody can tell if you're saying sequel-ite or sequel-lite or seque-lite on the one hand, or S-Q-L-ite or S-Q-L-lite or S-Q-lite on the other. AFAIK there is no official word on how the name…

Because the creator himself said it's an -ite suffix similar to minerals like bauxite, not -lite.

Interesting, thanks for mentioning that. I've always wondered about the origins of the name, never found anything, but now with your mention of "mineral" I was able to find this:

> (Hipp) How do I pronounce the name of the product? I say S-Q-L-ite, like a mineral.

> But I also hear a lot people say, "Sequel lite and SQL lite." You know, I don't care. Whatever comes off of your tongue easily is fine with me.

> (Q) But the official correct way is S-Q-L-ite?

> (Hipp) Yes, like a mineral.

https://www.listennotes.com/podcasts/the-changelog/why-sqlit...

So, he means SQL-ite, but doesn't want to proscribe this as the only way people should say it. I like all of that.

Maybe we should follow his example.

Post reply on HN