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

591–600 of 756 posts

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

#591

Post by vanviegen »

film42 wrote: post #452
pilif wrote: post #438

Earlier quoted context omitted.

That’s not true for Postgres however: due to its usage of a shared memory pool, whenever a subprocess is terminated unexpectedly, Postgres will kill all other processes and enter recovery mode, replaying the WAL, during which time it will not accept connection requests. It does this because it can’t possibly know whether the dying process did bad things to the shared memory pool.

You are correct! TIL, and thank you. Connection processes get a SIGQUIT, shared buffers cleared, and WAL replayed, but postmaster stays alive. It's effectively an online restart.

What's online about this restart? Just that the tcp port keeps listening? I assume all running transaction will have to be aborted, right? And connections dropped?

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

#592

Post by [deleted] »

the__alchemist wrote: post #396
ottavio wrote: post #33

Why should a developer use this for anything beyond a pet project? Just because it is written in Rust? All these "rewritten in rust" projects only reinforce the idea that a significant part of the rust community consists of software talibans and not of engineers who must deliver something that works and is reliable over time.

As someone who loves Rust the language and tool set: This class of projects [LLM rewrite of a reliable piece of software honed over decades) is embarrassing. If you are watching this and haven't used rust: Please don't judge the language by this part of its users.

[deleted]

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

#593

Post by dapperdrake »

jval43 wrote: post #480
chipotle_coyote wrote: post #363

Earlier quoted context omitted.

While I get the joke, as a technical writer, you might be surprised how often I've found myself as a defacto QA engineer: Me: This is what you said it does, and this is what it actually seems to do. Which one is right? Engineer: Shit.

Very carefully - and I mean extremely carefully - word it so that it describes what it does, while implying what it should do without confirming that it actually does that. Also helps if you fix the bug or change the behavior, the docs are still technically correct. I'm only partially kidding, I swear I've seen this a million times in documentation I read.

The joke is awesome.

Sadly, monospaced fonts kill sarcasm.

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

#594

Post by vanviegen »

TZubiri wrote: post #416
film42 wrote: post #262

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

Some see a 30 year old system and think "outdated", I see a 30 year old system and think "time tested." Clearly a process per connection is more stable and that's what I'm using. It's unclear what problem such optimizations are solving anyway, with the old way you could only support a million concurrent users with a single server? Are we missing out on supporting ten million concurrent users with 2 servers instead of…

> Clearly a process per connection is more stable

Even if those processes share most of their memory, and are written in a notoriously memory-unsafe language?

A significant performance improvement can well be the difference between being able to run the entire database on one beefy server, and having to shard. And that has a huge cost in terms of complexity and thus reliability and development time.

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

#595

Post by doublerabbit »

LtWorf wrote: post #307
shawabawa3 wrote: post #155

Earlier quoted context omitted.

> Why should a developer use this for anything beyond a pet project? If it _is_ 50% faster, then that's the reason Obviously like any new database it's very risky to use so probably only used for niche use cases at first, but if it turns out to be just as reliable as postgres and faster then why not?

It probably is 50% faster, probably by skipping flushing data to disk.

I'll make it 100% faster, skip saving any data to disk.

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

#596

Post by itomato »

sdevonoes wrote: post #251

Don’t understand these rewrites. - typically they are behind a single person. That’s usually bad because of spf - typically they are achieved in a very short amount of time, so the author hasn’t acquired any discipline in creating the project. That means it’s unlikely the author is going to stick to the project in the mid and long term - anyone that wants to contribute to the project needs to pay. Needs to pay tokens…

This year, not me.

In five? Everybody but me.

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

#597

Post by mirmor23 »

ikari_pl wrote: post #513
sevg wrote: post #509

Earlier quoted context omitted.

> That's too much effort to decipher a HN post. It would have been less effort than it took you to write this comment. Perhaps next time that you can’t be bothered, just ignore the comment and move on to another thread that meets your required spoonfeeding levels.

ignoring the part where you tell others how to live, I believe the effort estimates you used suggest you may struggle typing and project it on others. Doing a few searches and reviewing their results is effort. Google doesn't really say what went wrong if it's about Informix.

people complain when not spoonfed; however there seems to be no issues about spending effort to complain.

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

#598

Post by agumonkey »

malisper wrote: post #147

Hey author here. Wasn't expecting to see this up. To concisely give an overview of the project, I've been experimenting with using LLMs to build a better version of Postgres. Postgres is 30 years old and we've learned a lot about databases since hten. A lot of the techniques that work for doing a rewrite are also useful for doing a rearchitecture. I'm now working on a new, not yet published version of pgrust that inc…

Is it your first rewrite/migration (with or without llm) ?

good luck nonetheless

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

#599

Post by sgt »

happyweasel wrote: post #506

Porting perfectly working C code that has been in production for decades (and has a great track record wrt to security fixes) to rust is more or less an obfuscation challenge.

An academic exercise for sure. The Postgres team won't use this and take it forward, hence it will go stale and rot within months.

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

#600

Post by groundzeros2015 »

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.

They have the source right in front of them.
Post reply on HN