alt Hacker NewsThey use WAL in SQLite. If I continuously perform reads/writes so that they overlap with no gaps, I can make their VM go down because SQLite will not have time to initiate a checkpoint to trim the WAL file. SQLite waits for a time window without any active reads/writes before starting a WAL checkpoint. If there isn't one, the WAL will grow indefinitely, eating up all the disk space on the VM.
It's in SQLite's documentation, and almost no one switching to Sqlite seems to be aware of it because no one discusses it in blog posts like these. I guess most projects switching to SQLite have very low traffic and no malicious users (yet)
Replies
badatnames • today at 1:49 AM
Gippity claims this is only a problem with long-lived readers, the same is true in many other DBMS.
➕ show 1 reply
Could you go into more detail about this issue and provide some links to the documentation?
I'm absolutely no expert, I'm just reading about it now, but from the SQLite WAL documentation [0]:
> 7. There is the extra operation of checkpointing which, though automatic by default, is still something that application developers need to be mindful of.
and from their "checkpointing" documentation [1]:
> By default, SQLite does a checkpoint automatically when the WAL file reaches a threshold size of 1000 pages.
I'm only skimming but I see no mention of waiting for an idle time window.
Have you been successful in DoS'ing lobste.rs?
[0] https://sqlite.org/wal.html
[1] https://sqlite.org/wal.html#ckpt