]> granicus.if.org Git - postgresql/commit
Fix two ancient memory-leak bugs in relcache.c.
authorTom Lane <tgl@sss.pgh.pa.us>
Sun, 18 May 2014 20:51:46 +0000 (16:51 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sun, 18 May 2014 20:51:46 +0000 (16:51 -0400)
commit078b2ed291c758e7125d72c3a235f128d40a232b
tree703d66659bd11f5c203b59b2f13bfd3f1811f9fc
parent44cd47c1d49655c5dd9648bde8e267617c3735b4
Fix two ancient memory-leak bugs in relcache.c.

RelationCacheInsert() ignored the possibility that hash_search(HASH_ENTER)
might find a hashtable entry already present for the same OID.  However,
that can in fact occur during recursive relcache load scenarios.  When it
did happen, we overwrote the pointer to the pre-existing Relation, causing
a session-lifespan leakage of that entire structure.  As far as is known,
the pre-existing Relation would always have reference count zero by the
time we arrive back at the outer insertion, so add code that deletes the
pre-existing Relation if so.  If by some chance its refcount is positive,
elog a WARNING and allow the pre-existing Relation to be leaked as before.

Also, AttrDefaultFetch() was sloppy about leaking the cstring form of the
pg_attrdef.adbin value it's copying into the relcache structure.  This is
only a query-lifespan leakage, and normally not very significant, but it
adds up during CLOBBER_CACHE testing.

These bugs are of very ancient vintage, but I'll refrain from back-patching
since there's no evidence that these leaks amount to anything in ordinary
usage.
src/backend/utils/cache/relcache.c