> On Aug 12, 2026, at 11:12, Fujii Masao <[email protected]> wrote:
>
> 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?
+1
I never restart psql unless I’m making changes to psql itself. After restarting
the server, I usually just use \c to reconnect. So, avoiding accumulated leaks
is preferable.
>
> Regards,
>
> --
> Fujii Masao
> <v1-0001-Fix-psql-slash-option-leaks.patch>
V1 LGTM.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
