Re: Fix small psql slash option leaks

Hi Fujii,

On Wed, Aug 12, 2026 at 11:12 AM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> 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?
>
> Regards,
>
> --
> Fujii Masao

Could psql_scan_slash_option() return the static oom_buffer when
initPQExpBuffer() fails while parsing a quoted option? If so, the
caller's free() would be invalid.

--
Regards
Junwang Zhao