The current SQL implementation doesn't have any locking to prevent concurrent updates to the same log checkpoint row being updated by multiple processes. See #356 (comment) for discussion.
This works when the implementation is sqlite due to the global lock on transactions, but running with this persistence implementation with MySQL or MariaDB would be dangerous as it would allow two threads to successfully persist inconsistent checkpoints. Of course, only one of them would succeed, but this could allow a witness to sign and distribute inconsistent checkpoints during such races.
Options are:
- Make it clear that this is sqlite only: i.e. rename
internal/persistence/sql to internal/persistence/sqlite
- Make it support concurrent transactions properly so that it can work in MariaDB or MySQL
The current SQL implementation doesn't have any locking to prevent concurrent updates to the same log checkpoint row being updated by multiple processes. See #356 (comment) for discussion.
This works when the implementation is sqlite due to the global lock on transactions, but running with this persistence implementation with MySQL or MariaDB would be dangerous as it would allow two threads to successfully persist inconsistent checkpoints. Of course, only one of them would succeed, but this could allow a witness to sign and distribute inconsistent checkpoints during such races.
Options are:
internal/persistence/sqltointernal/persistence/sqlite