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
v1-0001-Fix-psql-slash-option-leaks.patch
Description: Binary data
