I believe both settings are valid and both pass the consistency test. As would be expected, If I set the Virtual Users to use the same data with innodb_snapshot_isolation set to 1 I see more of the messages from the district table, if I set them to all use different data then I still see them but not as frequently for the other tables. By default the data is selected at random so 2 virtual users can land on the same warehouse and in this scenario there are more messages. The workload will need to be changed in case of seeing these errors to retry the transaction as per the HammerDB issue.

marko
A change in the default isolation level will not be viewed kindly by any customer that is relying on that existing behaviour.
I understand that the change ensures RR satisfies PL-2.99 as it should and so the change is "correct". Is the use of the new default clearly and visible logged to make it clear what customers need to do to get bac to the old behavior if that is what they needed.
Steve Shaw, are the tests that are now failing assuming the old RR behaviour was meeting the actual criteria for RR? Are the problems you see with the snapshot isolation level set to ON a test problem or is the new behaviour wrong based on the RR (PL-2.99) ?

When testing MariaDB 11.8.1 with HammerDB (v5.0) the Virtual Users occasionally report the following message for multiple tables:
"mariaexec\/db server: Record has changed since last read in table 'new_order'",
If errors are raised the Virtual Users will stop e.g.
Error in Virtual User 15: Payment : mariaexec/db server: Record has changed since last read in table 'customer'
Vuser 15:FINISHED FAILED
After a sequence of tests the database continues to pass the HammerDB schema consistency checks (ie. the TPC-C consistency checks). After setting innodb_snapshot_isolation to 0 the messages/errors are not received. The database also continues to pass the HammerDB schema consistency checks (and I have not seen a scenario with earlier versions where MariaDB hasn't passed these checks).
Performance is identical with innodb_snapshot_isolation set to 0 or 1 (i.e. performance was within 1% at all datapoints tested and peak performance with innodb_snapshot_isolation set to 1 was 99.75% with it set to 0) An issue has been raised with HammerDB in case users observe the new behaviour.

mdcallag, thank you for your comment. With regard to the "quietly", you have a point, and we’d better take a note. While this change is mentioned in https://mariadb.com/kb/en/mariadb-11-6-2-release-notes/ and https://mariadb.com/kb/en/mariadb-11-7-1-release-notes/, not everyone is upgrading to every short-term release, but might stay on a long-term-supported release, such as 10.6, 10.11, 11.4, and upgrade to a newer long-term-supported release when one is released. There would seem to be some "documentation maintenance debt" that might not be adequately addressed. Currently the latest long-term-supported release series is 11.4.

When it comes to the parameter name, I would like to point out that at the start of the test innodb.lock_isolation that was added together with the parameter innodb_snapshot_isolation there are no gap locks or secondary indexes involved. There are other cases that involve secondary indexes and are helped by setting this parameter. The recent post https://mariadb.com/resources/blog/isolation-level-violation-testing-and-debugging-in-mariadb/ does not go into this level of detail. We are very thankful for the great work done by the folks behind https://jepsen.io/.

WRT enabling this so that you avoid bugs by default, I expect there to be far more bugs from workloads that depend (implicit and explicit) on the original behavior for InnoDB RR. And many of them will get bugs when they are quietly switched from original InnoDB RR to snapshot isolation on upgrading to 11.7.

The original InnoDB is complicated, isn't RR, but the different semantics it provides are valuable to some high throughput OLTP workloads.

In the InnoDB to MyRocks migrations, most workloads moved to RC with MyRocks because snapshot isolation will get more conflicts than InnoDB RR and the workloads preferred to avoid them. In some cases the workload owners were aware of the dependency on InnoDB RR and did the right thing so that their apps would continue to work. But in many cases the workload owners had no idea whether they depended on the special semantics of InnoDB RR. For those, we added logging to InnoDB to identify where they depended on it.

The my.cnf options in MyRocks for detecting usage of gap locks are: gap_lock_exceptions, gap_lock_log_file, gap_lock_raise_error,
gap_lock_write_log