Reasonable explanation of and suggested solution for the problem. Think I'd say "screw the housekeeping" and design for a garbage collector to periodically sweep the persistent store, likely as an independent process needing no data not already in that store. Then you're covered for the cases the transaction manager still drops.

That's essentially the process I used for an application which had a hierarchical graph-like database structure. The naive implementation would check if a node could be pruned (i.e. if it had no connections) every time a connection was removed. But it turned out it was a lot more performant to just periodically sweep for nodes with no connections like once a day.

That's part of what fsck would do for filesystems

A today solution for this problem, that is used on real life systems, is scheduling a regular restart of the programs (and claiming all its resources). Also, this must be fixed at OS level that must assume that they may have memory leaks, and clean up complete pages accordingly.

malloc use is a code-level issue, not an os-level issue. using it on systems that are memory sensitive is a terrible idea.

The article can be shortened to one line: malloc() has no place in a system that is concerned about memory leaks.