Proposed updates to https://sqlite.org/howtocorrupt.html
(1) By anonymous on 2021-05-23 11:22:32 [link] [source]
I was recently looking into a database corruption issue that ended up being caused by the POSIX lock quirks mentioned in section 2.2 of https://sqlite.org/howtocorrupt.html.
The code that caused this problem was a bit different than the situation that was described. Rather than operating in a multi-threaded environment, I was dealing with code that did a double fork to daemonize after already opening up an SQLite connection. For similar reasons mentioned in section 2.2, this resulted in POSIX locks to be released.
Could you update that section to mention this scenario as well? Having seen a reference to this might have sounded some alarm bells in my head and saved a bunch of debugging time Hopefully it can save others in the future!
(2) By Larry Brasfield (larrybr) on 2021-05-23 11:35:55 in reply to 1 [source]
Your suggestion would be well taken if it was about a new corruption scenario.
However, the section headed "Carrying an open database connection across a fork()", (numbered 2.6 today), appears to squarely encompass your scenario. Is there some reason it does not? Am I misunderstanding the corruption sequence you found?
(3) By anonymous on 2021-05-23 21:54:09 in reply to 2 [link] [source]
Ha nope, not at all, I just didn't see it!
Organizationally, it seems slightly nicer to have that close to 2.2 because they are so related, but I'm not sure how stable you want to keep the numbering.
Anyway, thanks for pointing that out!
(4) By Mike (mike.mcternan) on 2021-05-24 07:48:34 in reply to 1 [link] [source]
Section 2.6 seems pretty clear on interaction with fork():
Do not open an SQLite database connection, then fork(), then try to use that database connection in the child process.
Perhaps code under -DSQLITE_ENABLE_API_ARMOR could use pthread_atfork() to mark as invalid the database connections in child processes.