> On Nov 11, 2025, at 01:07, Yugo Nagata <[email protected]> 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 <[email protected]>
> <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 the behavior 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 infinite loop?
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/
