summaryrefslogtreecommitdiff
path: root/src
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2024-04-08 17:00:07 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2024-04-08 17:00:07 -0400
commita85e3ba1c9482dd04bec11588a5169a3430939af (patch)
tree9041c55e3d7a99527e5c9a50b910d05dc287cae2 /src
parent974374dcd394c80f37e20b692b7d8b122aa8ed33 (diff)
In psql, avoid leaking a PGresult after a query is cancelled.
After a query cancel, the tail end of ExecQueryAndProcessResults took care to clear any not-yet-read PGresults; but it forgot about the one it has already read. There would only be such a result when handling a multi-command string made with "\;", so that you'd have to cancel an earlier command in such a string to reach the bug at all. Even then, there would only be leakage of a single PGresult per cancel, so it's not surprising nobody noticed this. But a leak is a leak. Noted while re-reviewing 90f517821, but this is independent of that: it dates to 7844c9918. Back-patch to v15 where that came in.
Diffstat (limited to 'src')
-rw-r--r--src/bin/psql/common.c2
1 files changed, 2 insertions, 0 deletions
diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c
index 5973df2e39e..3b0710a9e2e 100644
--- a/src/bin/psql/common.c
+++ b/src/bin/psql/common.c
@@ -1662,6 +1662,8 @@ ExecQueryAndProcessResults(const char *query,
if (cancel_pressed)
{
+ /* drop this next result, as well as any others not yet read */
+ ClearOrSaveResult(result);
ClearOrSaveAllResults();
break;
}