Re: Make PQgetResult() not return NULL on out-of-memory error

On Tue, Nov 11, 2025 at 12:12 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
> 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?

Yes, that's a valid concern. If PQgetResult() keeps returning OOM_result due to
an out-of-memory error, some functions (e.g., discardAvailableResults()
in pgbench.c or PQexecFinish() in fe-exec.c) that expect PQgetResult() to
eventually return NULL could end up in an infinite loop.

To address this, callers need a way to distinguish between PGRES_FATAL_ERROR
and OOM. Functions that loop until PQgetResult() returns NULL should continue
if the result is PGRES_FATAL_ERROR, but should break if it's an OOM.
For example, one possible solution would be to add PGRES_OOM to
ExecStatusType, allowing callers to detect out-of-memory errors with
PQresultStatus() == PGRES_OOM.

Currently (even with the patch), OOM_result is returned only when
PQmakeEmptyPGresult() fails to allocate memory. But I guess there might be
other allocation failure paths. If we explicitly expose OOM_result,
we may also need to update PQgetResult() to return it in those other cases.
I'm not sure if that's the right direction, though... Probably we need to
look into the original commit that introduced OOM_result and its
related discussion.

Regards,

--
Fujii Masao