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. 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
