A database has to handle situations outside its control, e.g. someone cutting the power to the server. That should not result in a corrupted database, and with Postgres it doesn't.

The fundamental problem is that when you're sharing memory, you cannot safely just stop a single process when encountering an unexpected error. You do not know the current state of your shared data, and if it could lead to further corruption. So restarting everything is the only safe choice in this case.

Cars are designed with airbags?!

Like, they are supposed to crash?!?

> Relying on crashing as a bug recovery system is a good idea? Crashing is just part of the workflow? That's insane

Erlang users don't seem to agree with you

We do fix crashes etc, even if the postgres manages to restart.

I think the post upthread references an out-of-core extension we don't control, which in turn depends on many external libraries it doesn't control either...

It's all about trade off.

Building a database which is never gonna crash might be possible but at what cost? Can you name any single real world system archived that? Also, there can be a regression. More tests? Sure but again, at what cost?

While we are trying to get there, having a crash proof architecture is also a very practical approach.

We don't want stuff to crash. But we also want data integrity to be maintained. We also want things to work. In a world with extensions written in C to support a lot of cool things with Postgres, you want to walk and chew bubblegum on this front.

Though to your point, a C extension can totally destroy your data in other ways, and there are likely ways to add more barriers. And hey, we should fix bugs!

They are still debugging and patching the causes. The crash detection is just to try and prevent a single bug from bringing down the whole system.