PostgreSQL Support for Certificate Transparency Logs Now Available • Hacker News Board

Re: PostgreSQL Support for Certificate Transparency Logs Now Available

#21

Post by hiciu » Wed, Jan 08, 2025, 4:08 PM UTC

mobilemidget wrote: post #20

agwa wrote: post #12

Earlier quoted context omitted.

> If you let a disk run full weird shit happens. Only in buggy software that ignores errors from system calls. Obviously you can expect availability problems when you run out of space, but there's no excuse for losing data from committed transactions given that the OS will reliably report the error. > So I do strongly hope that besides changing software, they added some disk space monitoring. One of the action items…

Please enlighten me with some software examples that are free of bugs :)

It's not about being bug-free, it's about being crash-safe. You should be able to crash your software - either by pulling power cord from the server, killing process or turning disk read-only (similar to what happens when it's full), and your database should still survive.

Data corruption like that should just not happen. You have your journaled filesystems, you have your raid, zfs pools, and whatnot; all that is worth nothing if your database software can just say "I have encountered an error during write operation and now your data is inconsistent, good luck". This is exactly what journaling / write ahead log / innodb doublewrite buffer should prevent.

There is an article "Crash-only software: More than meets the eye" on lwn.net if you would like to read more about it. The postgres fsync bug is also vaguely related to the same issue, also worth reading.

Re: PostgreSQL Support for Certificate Transparency Logs Now Available

#22

Post by mobilemidget » Thu, Jan 09, 2025, 6:14 AM UTC

hiciu wrote: post #21

mobilemidget wrote: post #20

Earlier quoted context omitted.

Please enlighten me with some software examples that are free of bugs :)

It's not about being bug-free, it's about being crash-safe. You should be able to crash your software - either by pulling power cord from the server, killing process or turning disk read-only (similar to what happens when it's full), and your database should still survive. Data corruption like that should just not happen. You have your journaled filesystems, you have your raid, zfs pools, and whatnot; all that is wor…

Dont get me wrong, I agree it shouldn't happen. But that is not really my point, I also say you should not be surprised. And you kind of proof my point 'postgres fsync _bug_ is also vaguely related to the same issue'. Which would make the switch to PostgreSQL because of this, which could have been avoided by monitoring, even less strong choice. Who says there isn't a fsync like bug there still?

Corruption, empty files etc have happened before in case of exhausted disk space, with PostgreSQL, mysql and so on, so place and use additional safeguards, monitoring of disk space in this case. Because even if the data wouldn't be corrupted, a full disk leads to a failed service anyway which you want to avoid too. And even in case the table didnt get corrupted, new inserts, updates will fail, which might lead to 'missing' data too, which imho is also a sort of corruption.

Cars have airbags to avoid you getting seriously hurt in case of a crash. But dont be surprised if you do get serious hurt in case of a crash. Additional sensors that alert to the driver of a car to avoid accidents are important too.

Re: PostgreSQL Support for Certificate Transparency Logs Now Available

#23

Post by nijave » Sat, Jan 11, 2025, 4:46 PM UTC

mobilemidget wrote: post #9

nijave wrote: post #7

Earlier quoted context omitted.

That seems like a rather serious bug. Disappointing there's not more follow up with MariaDB

If you let a disk run full weird shit happens. But it reads to me as _we_, not mariadb, made a big oopsie and TADA \o/ now we change software. So I do strongly hope that besides changing software, they added some disk space monitoring.

I've ran Postgres out of disk space many times in lower environments and it's never corrupted the data. In progress transactions fail and rollback or are lost

It sounded like some of the motivation was the team having better understanding around Postgres. I think it's fair to replatform to something you have more experience running after having an incident with a different piece of software