On Tue, Nov 11, 2025 at 2:20 PM Fujii Masao <masao.fujii@gmail.com> wrote:
>
> On Tue, Nov 11, 2025 at 12:12 PM Chao Li <li.evan.chao@gmail.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
infiniteloop?
>
> 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.
This approach might not be good. Many applications currently would expect
PQgetResult() to return PGRES_FATAL_ERROR for any fatal error,
including out-of-memory. Introducing a new result status like PGRES_OOM
could break those applications, since they would need to be updated to
handle this new status explicitly.
Regards,
--
Fujii Masao
