Fix small psql slash option leaks

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

Responses

Browse pgsql-hackers by date

  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