]> granicus.if.org Git - postgresql/commit
Prevent memory leaks associated with relcache rd_partcheck structures.
authorTom Lane <tgl@sss.pgh.pa.us>
Sat, 13 Apr 2019 17:22:26 +0000 (13:22 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Sat, 13 Apr 2019 17:22:26 +0000 (13:22 -0400)
commit5f1433ac5e7f943b29ef01266b6b8fc915e6b917
tree748d40ab1b1ca5508b9250bdac695932a15dc0a3
parentc098509927f9a49ebceb301a2cb6a477ecd4ac3c
Prevent memory leaks associated with relcache rd_partcheck structures.

The original coding of generate_partition_qual() just copied the list
of predicate expressions into the global CacheMemoryContext, making it
effectively impossible to clean up when the owning relcache entry is
destroyed --- the relevant code in RelationDestroyRelation() only managed
to free the topmost List header :-(.  This resulted in a session-lifespan
memory leak whenever a table partition's relcache entry is rebuilt.
Fortunately, that's not normally a large data structure, and rebuilds
shouldn't occur all that often in production situations; but this is
still a bug worth fixing back to v10 where the code was introduced.

To fix, put the cached expression tree into its own small memory context,
as we do with other complicated substructures of relcache entries.
Also, deal more honestly with the case that a partition has an empty
partcheck list; while that probably isn't a case that's very interesting
for production use, it's legal.

In passing, clarify comments about how partitioning-related relcache
data structures are managed, and add some Asserts that we're not leaking
old copies when we overwrite these data fields.

Amit Langote and Tom Lane

Discussion: https://postgr.es/m/7961.1552498252@sss.pgh.pa.us
src/backend/partitioning/partdesc.c
src/backend/utils/cache/partcache.c
src/backend/utils/cache/relcache.c
src/include/utils/rel.h