SQLite Forum

What happens if I exit an app without closing the db?
Login

What happens if I exit an app without closing the db?

(1) By Proofrock (proofrock) on 2022-01-23 15:55:42 [link] [source]

Hi, first of all, thanks for your amazing work. I have an application written in Go using mattn's go-sqlite3.

Every code examples i see advise to close the databases when finished using them, but it's not always easy to track all the "exit paths" when an application closes. So it's generally not guaranteed that, when an application exits, a close was actually called.

mattn's implementation calls sqlite3_close_v2 when closing the db.

This said, is it a problem to exit an app without (always) calling this function? Can the database file remain in an inconsistent or corrupted state? In my experience, it never happened, but AFAIK it may.

See also my original question in go-sqlite's issue page.

Thanks a lot,

G.

(2) By Proofrock (proofrock) on 2022-01-23 16:31:27 in reply to 1 [link] [source]

As suggested by rittneje's answer to the original thread, this indirectly answers the question. Thanks all the same!

(3) By Larry Brasfield (larrybr) on 2022-01-23 16:46:08 in reply to 1 [link] [source]

Having not read its code or understood its genesis, I cannot speak to what go-sqlite3 will do. However, if it is a faithful rendition of the SQLite v3 code, (rather than merely misappropriating the name), and if no open transactions or unfinished backup objects exist, then the user-visiblea consequence of not closing "the db" before the application exits should be precisely the same as if it was closed before exiting. This is because sqlite3_close() (or its faithful rendition) is for reclaiming resources held by the "db" object, and under the stated precondition those resources are just memory. In the Go system, heap memory resources are reclaimed using garbage collection, but even if the garbage collector cannot run, the memory it might have collected will all become available to the system when the process exits, at least for any respectable OS.


a. Here, "user-visible" means visible in the ordinary usage patterns, not including examination of process memory when using a debugger or memory usage tracing diagnostics.

(6) By Proofrock (proofrock) on 2022-01-24 10:06:24 in reply to 3 [link] [source]

go-sqlite3 is a wrapper for sqlite (3), so under the hood it just calls the sqlite ABI.

Anyway, thanks for the answer, it's what I need:

the user-visible consequence of not closing "the db" before the application exits should be precisely the same as if it was closed before exiting

(4) By anonymous on 2022-01-23 20:36:06 in reply to 1 [link] [source]

it's not always easy to track all the "exit paths" when an application closes

Usually, it's a good idea to keep track of all resources that your program allocates (the garbage collector can only help you with the memory, but not e.g. kernel objects like file handles). The Go language has a defer keyword to guarantee that your clean-up function will run. Other languages offer destructors for similar purposes.

One reason not to do that is when you know that the operating system will clean it up for you right away, but if your code might become a part of a library and be called repeatedly, behaviour like that is essentially creating a resource leak.

(5.1) By Proofrock (proofrock) on 2022-01-24 14:57:26 edited from 5.0 in reply to 4 [source]

Fair enough, if I made a library I would track them - and it would be easier. When exiting an application, defer is not a solution, because:

  • it has the scope of a single method, and it could be cumbersome to apply "globally";
  • when exiting because of a SIGINT, defers are not called. You have to register an handler, and manage the situation;
  • os.Kill does not honor defers (nor SIGKILL AFAIK), and there's no workaround.

The last one is pesky, because it may be called in third-party code (even Go's, see log.Fatalf), so it's basically impossible. A mitigation is something like atexit, but it doesn't solve the os.Exit problem.

Luckily, what you say is correct: I don't have a problem to solve! ;-)