Re: Fix small psql slash option leaks

On Wed, Aug 12, 2026 at 12:12 PM 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.

BTW, while working on this, I found another issue around \getresults.

exec_command_getresults() sets pset.send_mode to
PSQL_SEND_GET_RESULTS before validating the optional argument. If the
argument is invalid, it returns PSQL_CMD_ERROR, so MainLoop
does not call SendQuery(). So, this send_mode state is not cleared and
remains set until the next command.

This can cause the next SQL command to behave unexpectedly, because it
is treated as a request to fetch pending results rather than as a normal
query. For example:

=# \startpipeline
=# SELECT 1;
=# \flushrequest
=# \getresults -1
\getresults: invalid number of requested results
=# SELECT 99;
?column?
----------
1

After the invalid \getresults, the following SELECT 99 is not
executed as expected. Instead, the stale PSQL_SEND_GET_RESULTS state
causes psql to fetch the pending result from the previous SELECT 1.

I'm thinking to address this separately as a follow-up after committing the
memory leak fix.

Regards,

--
Fujii Masao