3 ms·
"PostgreSQL used fsync incorrectly for 20 years" https://archive.fosdem.org/2019/schedule/event/postgresql_fsync/ https://archive.fosdem.org/2019/schedule/even
by Thaxll 10mo ago
"PostgreSQL used fsync incorrectly for 20 years"
https://archive.fosdem.org/2019/schedule/event/postgresql_fsync/ https://archive.fosdem.org/2019/schedule/event/postgresql_fs...
It did not prevent people from using it. You won't find a database that has the perfect durability, ease of use, performance ect.. It's all about tradeoffs.
- dijit 10mo agoRealistically speaking, postgresql wasn’t handling a failed call to fsync, which is wrong: but materially different from a bad design or errors in logic stemming from many areas. Postgresql was able to fix their bug in 3 lines of code, how many for the parent system? I understand your core thesis (sometimes durability guarantees aren’t as needed as we think) but in postgresql’s case, the edge was incredibly thin. It would have had to have been: a failed call to fsync and a system level failure of the host before another call to fsync (which are reasonably common). It’s far too apples to oranges to be meaningful to bring up I am afraid.
- Thaxll 10mo agoNATS allows you to fsync every calls, it's not just the default value.