Hacker News Reader

Comment by threeseed | Hacker News Reader

I was talking about data consistency more broadly. "However, two writes (215 and 218) succeeded, even though they threw an exception claiming that a failure occurred". This obviously isn't ideal behaviour from the perspective of a developer but isn't necessarily not correct.

My broader point was that you need to assume the worst from your database in the application layer. Which I think you missed.

View on HN

I read your post as FUD regarding Postgres.

That article has various issues, for example, calling Postgres commit protocol as a special case of two phase commit is not really correct. Postgres has 2pc: http://www.postgresql.org/docs/9.2/static/sql-prepare-transa... but that was not tested.

The described behavior is "expected" and "understood". Saying that "you should assume worst from your database" is not something I would ever use for describing DB with ACID semantics.

I wasn't spreading FUD about anything. From the article there was issues with every databases expected behaviour. My point again was that you should expect and manage failure in your application layer. It's what sensible architecture looks like.

And ACID does NOT guarentee that you will not lose data. It is a theory not an implementation. I have lost data with both Oracle and Teradata due to bugs.

Well, you said that Postgres had data consistency errors (referencing Aphyr articles). This is not true (at least regarding that article).

Aphyr article about Postgres could be renamed to call-me-maybe-acid-db-over-the-network and could remain the same.

Reply on news.ycombinator.com