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