Hi Fujii, On Wed, Aug 12, 2026 at 11:12 AM 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? > > 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
