aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2021-03-18 21:44:42 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2021-03-18 22:22:47 -0400
commitd303849b059c3c315e5a8d4239016f8328f3296c (patch)
tree17ab9fa9eeb00fe51c7fdcbf6415b316dd909f79 /src/backend/access/gist
parent415ffdc2205e209b6a73fb42a3fdd6e57e16c7b2 (diff)
downloadpostgresql-d303849b059c3c315e5a8d4239016f8328f3296c.tar.gz
postgresql-d303849b059c3c315e5a8d4239016f8328f3296c.zip
Don't leak compiled regex(es) when an ispell cache entry is dropped.
The text search cache mechanisms assume that we can clean up an invalidated dictionary cache entry simply by resetting the associated long-lived memory context. However, that does not work for ispell affixes that make use of regular expressions, because the regex library deals in plain old malloc. Hence, we leaked compiled regex(es) any time we dropped such a cache entry. That could quickly add up, since even a fairly trivial regex can use up tens of kB, and a large one can eat megabytes. Add a memory context callback to ensure that a regex gets freed when its owning cache entry is cleared. Found via valgrind testing. This problem is ancient, so back-patch to all supported branches. Discussion: https://postgr.es/m/3816764.1616104288@sss.pgh.pa.us
Diffstat (limited to 'src/backend/access/gist')
0 files changed, 0 insertions, 0 deletions