Commenting myself on my blog post, because I got one remark about blogging on Oracle Database issues while I'm working for a competitor database.
I've always blogged about features as well as issues. Any software has strenghts and weaknesses, and the most important is not to ignore them. This commit issue is not new, is well known, has been experienced by users, but probably never get a proper support analyis because of the lack of traces for it (the dirty reads are only in memory). There's nobody to blame for that. Documenting it, like this reproducible test case, is the right way to understand it when it happens. This is the goal of this post. Those short-term dirty reads during a crash are probably not a problem when understood. Without an clear explanation, it would hurt the trust on all infrastructure components.
The comparison with PostgreSQL was there to show that the PostgreSQL community would consider that as a bug and does it the right way. There's a reason for that: the balance between performance and ACID properties is different between commercial (who favors performance benchmarks) and open source community (who favors transparency and trust).
The comparison with YugabyteDB was there to generalize the idea of atomic operations and consensus. There's also a reason for that: a distributed system on a cloud environment, or commodity hardware, experiences more infrastructure failures than a monolithic database machine like Exadata.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Commenting myself on my blog post, because I got one remark about blogging on Oracle Database issues while I'm working for a competitor database.
I've always blogged about features as well as issues. Any software has strenghts and weaknesses, and the most important is not to ignore them. This commit issue is not new, is well known, has been experienced by users, but probably never get a proper support analyis because of the lack of traces for it (the dirty reads are only in memory). There's nobody to blame for that. Documenting it, like this reproducible test case, is the right way to understand it when it happens. This is the goal of this post. Those short-term dirty reads during a crash are probably not a problem when understood. Without an clear explanation, it would hurt the trust on all infrastructure components.
The comparison with PostgreSQL was there to show that the PostgreSQL community would consider that as a bug and does it the right way. There's a reason for that: the balance between performance and ACID properties is different between commercial (who favors performance benchmarks) and open source community (who favors transparency and trust).
The comparison with YugabyteDB was there to generalize the idea of atomic operations and consensus. There's also a reason for that: a distributed system on a cloud environment, or commodity hardware, experiences more infrastructure failures than a monolithic database machine like Exadata.