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

Hacking on PostgreSQL is hard

rhaas.blogspot.com

Post reply on HN
Print view View original

51–56 of 56 posts

Re: Hacking on PostgreSQL is hard

#51

Post by brazzy »

hyperman1 wrote: post #16

What's missing in this post is a deep analysis of what the bugs are and what was causing them, in a 5 times why sense. Especially if they all seem dumb stuff at first. There are some deep lessons about programming in this Factorio Friday Facts: https://factorio.com/blog/post/fff-366 and I wonder if postgres doesn't look like fig.1 from this blog post, before the refactoring.

I'm pretty sure the answer is usually "concurrency". The examples alluded to in TFA sound like it. Handling concurrency is notably extremely hard, and an RDBMS is what other applications use to solve their hairy concurrency problems so they don't have to.

Re: Hacking on PostgreSQL is hard

#52

Post by int_19h »

garyrob wrote: post #36
zie wrote: post #35

Earlier quoted context omitted.

It can still happen sometimes, but it's very rare that it crashes and even more rare that it corrupts as well. The good news, the chances of it corrupting your data silently was basically zero, then and now. However back then MySQL seemed like it went out of it's way to corrupt your data. The only "bonus" is, it did it all silently, so nobody ever noticed until they went looking. With MariaDB(the successor) it's pret…

Could be; but it never happened to me with MySQL! Maybe it depends on on how far back in the day you go...? :)

Around early 00s, it was already common wisdom among the web devs that, when it comes to free RDBMS, if you want speed, you use MySQL; and if you want consistency and reliability, then Postgres is where it's at.

(Most people wanted speed.)

Re: Hacking on PostgreSQL is hard

#53

Post by maxbond »

irjustin wrote: post #32
ncann wrote: post #28

Could it be that RDBMS is just inherently very complex? Reminds me of this classic comment about Oracle Database: https://news.ycombinator.com/item?id=18442941 To quote part of it > Oracle Database 12.2. > It is close to 25 million lines of C code. > What an unimaginable horror! You can't change a single line of code in the product without breaking 1000s of existing tests. Generations of programmers have worked on th…

> The only reason why this product is still surviving and still works is due to literally millions of tests! Personally I consider this a good thing. It's a sign of a really mature codebase where lots of edge cases are known + accounted for. Even if the underlying code was really well written, simply the number of edge cases hamstring any "quick hacks". Complex, runs reliably, easy to hack - Pick two

Tests are great, but relying on them in this way is like relying on a net to catch you without wearing a harness. It's a good thing if your last line of defense is reliable enough to catch you. But if you're relying on it, it's not a last line of defense, it's the only one.

You should be able to work on software because you understand how it works and what the ramifications of a given change are. Tests and code reviews provide redundancy. But here, they aren't providing redundancy, they're bearing the load.

What provides redundancy if tests are missing, broken, or misinterpreted? Have you ever fixed a bug, gone to write a test for it - and found the test already exists but passed spuriously?

Re: Hacking on PostgreSQL is hard

#54

Post by jiggawatts »

sanxiyn wrote: post #31
ncann wrote: post #28

Could it be that RDBMS is just inherently very complex? Reminds me of this classic comment about Oracle Database: https://news.ycombinator.com/item?id=18442941 To quote part of it > Oracle Database 12.2. > It is close to 25 million lines of C code. > What an unimaginable horror! You can't change a single line of code in the product without breaking 1000s of existing tests. Generations of programmers have worked on th…

I think it is not RDBMS, rather combinatorial explosion of configuration/flag/option/platform is insidious and we, software engineering as a field, don't know how to do it well. I think it is one of the largest impact problem in software engineering if it can be improved. Maybe a way to restrict flag interaction and reduce support and test matrix as a result.

Something I enjoyed was listening to the talks by the LibreSSL team cleaning up the mess in OpenSSL that (in part) caused the Heartbleed bug.

One of their strategies was to drop the macro soup and simply program against the "libc we would like to have", and then add compatibility shims to materialise their ideal libc instead of conditional compilation at the point of use.

Re: Hacking on PostgreSQL is hard

#55

Post by zie »

garyrob wrote: post #36
zie wrote: post #35

Earlier quoted context omitted.

It can still happen sometimes, but it's very rare that it crashes and even more rare that it corrupts as well. The good news, the chances of it corrupting your data silently was basically zero, then and now. However back then MySQL seemed like it went out of it's way to corrupt your data. The only "bonus" is, it did it all silently, so nobody ever noticed until they went looking. With MariaDB(the successor) it's pret…

Could be; but it never happened to me with MySQL! Maybe it depends on on how far back in the day you go...? :)

Did you ever go looking for corruption? :) Most people don't.

Re: Hacking on PostgreSQL is hard

#56

Post by garyrob »

zie wrote: post #55
garyrob wrote: post #36

Earlier quoted context omitted.

Could be; but it never happened to me with MySQL! Maybe it depends on on how far back in the day you go...? :)

Did you ever go looking for corruption? :) Most people don't.

The database couldn't be used anymore! Pretty severe corruption.
Post reply on HN