diff options
| author | Tom Lane <tgl@sss.pgh.pa.us> | 2021-02-02 13:49:08 -0500 |
|---|---|---|
| committer | Tom Lane <tgl@sss.pgh.pa.us> | 2021-02-02 13:49:08 -0500 |
| commit | 5868913943441f9d0a5776f1367f3f98268b10a8 (patch) | |
| tree | aec2517dabe4409a84952369b27720dd33825a23 /contrib/postgres_fdw/postgres_fdw.c | |
| parent | dae5af6c19f20d954179df5e15afa649fbabb101 (diff) | |
| download | postgresql-5868913943441f9d0a5776f1367f3f98268b10a8.tar.gz postgresql-5868913943441f9d0a5776f1367f3f98268b10a8.zip | |
Fix ancient memory leak in contrib/auto_explain.
The ExecutorEnd hook is invoked in a context that could be quite
long-lived, not the executor's own per-query context as I think
we were sort of assuming. Thus, any cruft generated while producing
the EXPLAIN output could accumulate over multiple queries. This can
result in spectacular leakage if log_nested_statements is on, and
even without that I'm surprised nobody complained before.
To fix, just switch into the executor's context so that anything we
allocate will be released when standard_ExecutorEnd frees the executor
state. We might as well nuke the code's retail pfree of the explain
output string, too; that's laughably inadequate to the need.
Japin Li, per report from Jeff Janes. This bug is old, so
back-patch to all supported branches.
Discussion: https://postgr.es/m/CAMkU=1wCVtbeRn0s9gt12KwQ7PLXovbpM8eg25SYocKW3BT4hg@mail.gmail.com
Diffstat (limited to 'contrib/postgres_fdw/postgres_fdw.c')
0 files changed, 0 insertions, 0 deletions