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

On Tue, Nov 11, 2025 at 2:43 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
> > 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.
>
> Not sure about that. We might or might not be able to make progress
> if the caller keeps calling PQgetResult. But if it stops after an
> OOM report then we might as well just close the connection, because
> there is no hope of getting back in sync.
>
> I'm inclined to think that it's correct that we should return
> OOM_result not NULL if we couldn't make a PGresult, but further
> analysis is needed to make sure that libpq can make progress
> afterwards. I don't think we should expect applications to
> involve themselves in that recovery logic, because they won't,
> and most certainly won't test it carefully.
>
> The whole project might be doomed to failure really. I think
> that one very likely failure if we are approaching OOM is that
> we can't enlarge libpq's input buffer enough to accept all of
> a (long) incoming server message. What hope have we got of
> getting out of that situation?

When pqCheckInBufferSpace() fails to enlarge the input buffer and PQgetResult()
returns PGRES_FATAL_ERROR, I noticed that PQgetResult() sets asyncStatus to
PGASYNC_IDLE. This means subsequent calls to PQgetResult() will return NULL
even in OOM case, so functions looping until NULL won't end up in an
infinite loop.
Of course, issuing another query on the same connection afterward could be
problematic, though.

I'm still not sure this behavior is correct, but I'm just wondering if
asyncStatus should be reset to PGASYNC_IDLE also when OOM_result is returned.

Regards,

--
Fujii Masao