Kyotaro Horiguchi <horikyota....@gmail.com> writes:
> Recently a cache reference leak was reported then fixed [1].
> I happened to notice a similar possible leakage in
> removeEtObjInitPriv. I haven't found a way to reach the code, but can
> be forcibly caused by tweaking the condition.
> Please find the attached.
Ugh. recordExtObjInitPriv has the same problem.
I wonder whether there is any way to teach Coverity, or some other
static analyzer, to look for code paths that leak cache refcounts.
It seems isomorphic to detecting memory leaks, which Coverity is
reasonably good at.
regards, tom lane
