Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The .dump command creates a read transaction[0], so it shouldn't block any writes.

From the SQLite docs:

  When a SAVEPOINT is the outer-most savepoint and it is not within a BEGIN...COMMIT then the behavior is the same as BEGIN DEFERRED TRANSACTION
Internally, the .dump command only runs SELECT queries.

[0]: https://github.com/sqlite/sqlite/blob/3748b7329f5cdbab0dc486...



A read transaction does block writes, unless you enable WAL mode, which I forgot to mention.


WAL Mode is the default anyway, I thought.


It is not, due to the many restrictions upon it, and warnings in its use.

“To accelerate searching the WAL, SQLite creates a WAL index in shared memory. This improves the performance of read transactions, but the use of shared memory requires that all readers must be on the same machine [and OS instance]. Thus, WAL mode does not work on a network filesystem.”

“It is not possible to change the page size after entering WAL mode.”

“In addition, WAL mode comes with the added complexity of checkpoint operations and additional files to store the WAL and the WAL index.”

https://www.vldb.org/pvldb/vol15/p3535-gaffney.pdf

SQLite does not guarantee ACID consistency with ATTACH DATABASE in WAL mode. “Transactions involving multiple attached databases are atomic, assuming that the main database is not ":memory:" and the journal_mode is not WAL. If the main database is ":memory:" or if the journal_mode is WAL, then transactions continue to be atomic within each individual database file. But if the host computer crashes in the middle of a COMMIT where two or more database files are updated, some of those files might get the changes where others might not.

https://www.sqlite.org/lang_attach.html


True, but I think there aren't many reasons to not run in WAL mode by default.


Au contraire.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: