On Tue, Nov 11, 2025 at 2:20 PM Fujii Masao <[email protected]> wrote: > > On Tue, Nov 11, 2025 at 12:12 PM Chao Li <[email protected]> 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.
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
