I see no ambiguity in the language you quoted. There are API routines for disposing of the objects (sqlite3\_blob\_close(), sqlite3\_finalize(), sqlite3\_backup\_finish()), and when those are eventually called on all such objects associated with a connection, the library will, in addition to deallocating those specific resources (or resource holders), do what sqlite3\_close\_v2() would have done if those objects had not been outstanding. That's the promise, as I read it. It is a convenience that the order in which those 4 done-with-this routines are called is not forced. And in some environments, (such as C++ where the resources are often held in objects and released upon destructor calls), the order of release can be tedious or difficult to arrange. The document you quote would be lying if sqlite3\_close\_v2() were to simply hang until, presumably, some other thread got around to disposing of those other objects. What do you think would make that return promise more clear, without going into the implementation details that have no place in interface documentation? Your obligations, (assuming you wish to avoid leaking memory and file handles), are simple: for each created instance of those 4 object types, (connection, blob handle, statement, backup object), call their associated done-with-this routine, in any order you like, without using them afterward. No such call will hang.