| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Fix small psql slash option leaks |
| Date: | 2026-08-12 03:12:08 |
| Message-ID: | CAHGQGwEh3R3=1tx_a5=fTDJ+ycuwxWMEn6bG_Yt4B5P+hE7AVw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
Attached is a small patch that fixes a few cases where the result of
psql_scan_slash_option() was not freed.
psql_scan_slash_option() returns a malloc'd string, and most callers
either free it directly or transfer ownership to longer-lived psql
state. But there seems a few exceptions.
The patch covers the meta-commands: \getresults, \gset in pipeline mode,
\restrict, and \unrestrict.
I don't think these are severe leaks. The leaked object is just the
string returned by psql_scan_slash_option(), so the amount is small in
typical use and is reclaimed when the psql process exits. However, the
leak can accumulate in a long-running interactive psql session if these
are repeatedly exercised. Since nearby callers generally free
these strings explicitly, it seems worthwhile to make these cases
consistent as well.
I'm thinking of backpatching this to all supported versions. In v17 and
older, only the \restrict and \unrestrict cases apply, so those
branches would need only that part of the fix.
Thought?
Regards,
--
Fujii Masao
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-Fix-psql-slash-option-leaks.patch | application/octet-stream | 2.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2026-08-12 03:21:30 | Re: index prefetching |
| Previous Message | Hayato Kuroda (Fujitsu) | 2026-08-12 03:06:10 | RE: 019_replslot_limit.pl might fail due to checkpoint skipped |