3 ms·

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

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/3748b7329f5cdbab0dc486ac484c1801fa6f08dc/src/shell.c.in#L8439 https://github.com/sqlite/sqlite/blob/3748b7329f5cdbab0dc486...

oefrha 3y ago
A read transaction does block writes, unless you enable WAL mode, which I forgot to mention.
- diarrhea 3y ago
  WAL Mode is the default anyway, I thought.
  - chasil 3y ago
    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 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 https://www.sqlite.org/lang_attach.html
- polyrand 3y ago
  True, but I think there aren't many reasons to not run in WAL mode by default.
  - chasil 3y ago
    Au contraire.

oefrha 3y ago

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

diarrhea 3y ago
WAL Mode is the default anyway, I thought.
- chasil 3y ago
  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 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 https://www.sqlite.org/lang_attach.html
polyrand 3y ago
True, but I think there aren't many reasons to not run in WAL mode by default.
- chasil 3y ago
  Au contraire.