New #Jepsen report! We worked with @YugaByte to evaluate YugaByte DB 1.3.1's beta support for serializable SQL transactions. We found 2 safety bugs including anti-dependency cycles (now fixed), and availability issues like a slow leak in backend processes. https://jepsen.io/analyses/yugabyte-db-1.3.1 …
-
Show this thread
-
YugaByte DB doesn't pass Jepsen presently; some of the safety issues we identified in testing are still extant. For instance, YugaByte DB has a race condition which allows `DEFAULT NOW()` columns to be initialized to `NULL`, rather than a timestamp.https://github.com/YugaByte/yugabyte-db/issues/2021 …
1 reply 0 retweets 1 likeShow this thread -
The impact of this issue (like many of the problems we found in schema modification) is limited to a short time around table creation. Schema changes in general aren't transactional, so this might occur during other changes, like adding/removing columns--we haven't looked yet.
1 reply 0 retweets 3 likesShow this thread -
So... when YugaByte says they "pass Jepsen" (https://blog.yugabyte.com/yugabyte-db-distributed-sql-api-passes-jepsen-tests/ …) they're only talking about the parts of the test suite which look at changes to data records in the absence of schema changes. We think that's most important for users, and it's the vast majority of our tests
1 reply 0 retweets 2 likesShow this thread
An open question in my mind: can non-transactional schema changes (e.g. adding a column) result in *data-level* serializability violations? What would those anomalies look like? I'm honestly not sure, but it's something we can explore going forward!
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.