> On Nov 11, 2025, at 01:07, Yugo Nagata <nagata@sraoss.co.jp> wrote:
>
> Hi,
>
> Currently, PQgetResult() returns NULL not only when no results remain for
> a sent query, but also when an out-of-memory error occurs, except when
> PGconn itself is NULL. As a result, users cannot distinguish between query
> completion and an out-of-memory error when PQgetResult() returns NULL.
>
> The result returned by PQgetResult() is generated by either pqPipelineProcessQueue()
> or getCopyResult(). While pqPipelineProcessQueue() never returns NULL, even in the
> case of an out-of-memory error, getCopyResult() may return NULL.
> Therefore, I propose modifying getCopyResult() so that it never returns NULL, but
> instead returns OOM_result, as pqPipelineProcessQueue() does.
>
> I’ve attached a patch for this.
>
> Regards,
> Yugo Nagata
>
> --
> Yugo Nagata <nagata@sraoss.co.jp>
> <0001-Make-PQgetResult-not-return-NULL-on-out-of-memory-er.patch>
This is a front-end OOM. As it changes the behavior of PGgetResult(), I am just worrying about if callers can handle
thebehavior change.
For example, pgbench:
* When pgbench calls readCommandResponse()
* If OOM happens, PQgetResult() returns OOM_reslt whose resultState is PGRES_FATAL_ERROR
* readCommandResponse() will goto the error tag, then discardAvailableResults() will be called
* discardAvailableResults() only returns when res is NULL, so that, would discardAvailableResults() fall into an
infiniteloop?
Otherwise the patch looks good to me. I agree that is a good idea to distinguish a client OOM error from a server side
error.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
