|
@jepsen_io | |||||
|
So... when YugaByte says they "pass Jepsen" (blog.yugabyte.com/yugabyte-db-di…) 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
|
||||||
|
||||||
|
Jepsen
@jepsen_io
|
5. ruj |
|
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. jepsen.io/analyses/yugab…
|
||
|
|
||
|
Jepsen
@jepsen_io
|
5. ruj |
|
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. github.com/YugaByte/yugab…
|
||
|
|
||
|
Jepsen
@jepsen_io
|
5. ruj |
|
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.
|
||
|
|
||
|
Jepsen
@jepsen_io
|
5. ruj |
|
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!
|
||
|
|
||