aboutsummaryrefslogtreecommitdiff
path: root/src/backend/executor/nodeModifyTable.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2025-08-02 19:43:53 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2025-08-02 21:59:46 -0400
commit7f6ededa764b287ba593a2bb7fd566df8053213e (patch)
treeada62ee844caa2ee85aa3e17eccb5e8522177641 /src/backend/executor/nodeModifyTable.c
parent2c7b4ad24dda86a73d80df063e9a56c3ecb1e4bb (diff)
downloadpostgresql-7f6ededa764b287ba593a2bb7fd566df8053213e.tar.gz
postgresql-7f6ededa764b287ba593a2bb7fd566df8053213e.zip
Suppress complaints about leaks in TS dictionary loading.
Like the situation with function cache loading, text search dictionary loading functions tend to leak some cruft into the dictionary's long-lived cache context. To judge by the examples in the core regression tests, not very many bytes are at stake. Moreover, I don't see a way to prevent such leaks without changing the API for TS template initialization functions: right now they do not have to worry about making sure that their results are long-lived. Hence, I think we should install a suppression rule rather than trying to fix this completely. However, I did grab some low-hanging fruit: several places were leaking the result of get_tsearch_config_filename. This seems worth doing mostly because they are inconsistent with other dictionaries that were freeing it already. Author: Tom Lane <tgl@sss.pgh.pa.us> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/285483.1746756246@sss.pgh.pa.us
Diffstat (limited to 'src/backend/executor/nodeModifyTable.c')
0 files changed, 0 insertions, 0 deletions