4 ms·

Why isn't PostgreSQL in the list on the first page? It is in the [blog posts] page though. I would love to see the multixact data corruption problems introduce

Why isn't PostgreSQL in the list on the first page? It is in the [blog posts] page though. I would love to see the multixact data corruption problems introduced in 9.3 analyzed, and see if he can verify them to be solved in the latest version.

rdtsc 11y ago
(Not author) but from what I remember PostreSQL was a bit of a funny case. It was about partitions between clients and a single database server. In most other cases, it was analysis of distributed back-end server instances. Not that those failures are not important but it is just harder to compare it seems with the others.
- lomnakkus 11y ago
  Yeah, basically with PostgreSQL it boils down to the fact that even if a client receives an error on commit, its writes may in fact have succeeded -- and it cannot assume that they haven't. (Since the final "ack" that everything went well may not make it.) As an example: This means that idempotency is really important if you're doing any kind of retries on commit failure. EDIT: Another example: If you're doing application-level optimistic concurrency control (using e.g. an incrementing version number) you can end up in a situation where an update appears to conflict with itself. Usually, though, this isn't a big concern since client<->server paritions are usually catastrophic anyway. (Off the top of my head that's what I can recall -- there may be other things to be gleaned from the original article.) [1] At least for all practical purposes.
  - biokoda 11y ago
    > Yeah, basically with PostgreSQL it boils down to the fact that even if a client receives an error on commit, its writes may in fact have succeeded -- and it cannot assume that they haven't. This is true for almost every database. Otherwise they would require a distributed transaction between the client and server.
    - lomnakkus 11y ago
      Indeed, but given that we were talking about $DISTSYS vs. $CONCRETE_THING, I just mentioned the $CONCRETE_THING by name. You are of course technically right... which is the best kind of right! :)
amitlan 11y ago
Not quite sure whether something like multixact data corruption is symptomatic of the kind of underlying issues in database system implementations that Jepsen is after. I may be wrong though.
- deleted 11y ago
  [deleted]
- Jweb_Guru 11y ago
  It wasn't. It's also rather difficult to trigger. I have no doubt that aphyr could do stuff like that if he so chose, but I think pounding on getting a reproducible test case for Postgres's subtle serializable bug would be more his speed.
threeseed 11y ago
PostgreSQL was tested in single mode. All others distributed. Apples and Oranges.

rdtsc 11y ago

(Not author) but from what I remember PostreSQL was a bit of a funny case. It was about partitions between clients and a single database server. In most other cases, it was analysis of distributed back-end server instances. Not that those failures are not important but it is just harder to compare it seems with the others.

lomnakkus 11y ago
Yeah, basically with PostgreSQL it boils down to the fact that even if a client receives an error on commit, its writes may in fact have succeeded -- and it cannot assume that they haven't. (Since the final "ack" that everything went well may not make it.) As an example: This means that idempotency is really important if you're doing any kind of retries on commit failure. EDIT: Another example: If you're doing application-level optimistic concurrency control (using e.g. an incrementing version number) you can end up in a situation where an update appears to conflict with itself. Usually, though, this isn't a big concern since client<->server paritions are usually catastrophic anyway. (Off the top of my head that's what I can recall -- there may be other things to be gleaned from the original article.) [1] At least for all practical purposes.
- biokoda 11y ago
  > Yeah, basically with PostgreSQL it boils down to the fact that even if a client receives an error on commit, its writes may in fact have succeeded -- and it cannot assume that they haven't. This is true for almost every database. Otherwise they would require a distributed transaction between the client and server.
  - lomnakkus 11y ago
    Indeed, but given that we were talking about $DISTSYS vs. $CONCRETE_THING, I just mentioned the $CONCRETE_THING by name. You are of course technically right... which is the best kind of right! :)

amitlan 11y ago

Not quite sure whether something like multixact data corruption is symptomatic of the kind of underlying issues in database system implementations that Jepsen is after. I may be wrong though.

deleted 11y ago
[deleted]
Jweb_Guru 11y ago
It wasn't. It's also rather difficult to trigger. I have no doubt that aphyr could do stuff like that if he so chose, but I think pounding on getting a reproducible test case for Postgres's subtle serializable bug would be more his speed.

threeseed 11y ago

PostgreSQL was tested in single mode. All others distributed. Apples and Oranges.