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

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?

regards, tom lane