Non-WAL sqlite3_rsync issue
(1) By Bo Lindbergh (_blgl_) on 2025-05-02 05:05:35 [source]
After this commit, sqlite3_rsync can be used to turn WAL mode on or off in the destination database. This is rude; other software connecting to the same database may be confused if WAL mode changes behind its back. Also, what happens if page 1 in the main database file says "WAL" while the latest version of page 1 in the WAL file says "non-WAL"?
Suggested improved behaviour: the origin and the destination must be either both WAL or both non-WAL.
(2) By Richard Hipp (drh) on 2025-05-02 11:05:40 in reply to 1 [link] [source]
I think it is ok for the replica to be converted into WAL mode. But you are correct that it could be bad to convert the replica out of WAL mode as that would disrupt other connected clients. So the code I have on my desktop now, and which I will probably check in later this morning, does just that.
- If the origin and replica both start in WAL mode, no mode changes is made to the journal_mode of the replica.
- If the origin and replica bpth start in non-WAL, no changes are made to the journal_mode of the replica.
- If the origin starts in WAL mode and the replica starts in non-WAL, then the replica is converted into WAL mode.
- If the origin starts in non-WAL mode and the replica starts in WAL, then content is synced, but the replicate continues to be in WAL mode.
(3) By Richard Hipp (drh) on 2025-05-02 11:29:18 in reply to 2 [link] [source]
Dan points out that case 4 above would not actually disrupt existing clients. The conversion from WAL into non-WAL does not actually occur until the last client disconnects and the -wal file is deleted. So the prior code was safe as written.
On the other hand, there is no harm in making WAL-mode sticky, which is what the current tip-of-trunk does.