On Wed, 12 Nov 2025 18:09:28 +0900
Fujii Masao <masao.fujii@gmail.com> wrote:
> > > Therefore, I wonder about closing the connection and resetting the status
> > > when OOM_result is retunred, by callling pqDropConnection() as handleFatalError() does.
> > > In this case, the connection status should also be set to CONNECTINO_BAD.
>
> There are many code paths in libpq that can trigger an out-of-memory error.
> However, this patch makes libpq drop the connection when OOM_result is returned,
> which likely covers only a subset of those cases. So I'm not sure dropping
> the connection only for OOM_result would meaningfully improve things.
>
> Perhaps it would be more consistent to drop the connection for any
> internal libpq error
> such as out-of-memory, though that might require invasive code changes and coul
> break existing applications, I'm afraid.
I see that some internal errors are handled by calling handleFatalError()
(i.e. dropping the connection), but for some OOM errors in libpq/fe-protocol3.c,
functions just fail silently. Therefore, I'm not sure if dropping the connection
for any internal libpq errors is good idea.
If an OOM during the preparation of a result of PGgetResult() is not considered
a fatal error should terminate the connection, then is it the application's
responsibility to determine whetehr the connection can continue to be used?
In that case, a way to detect OOM failure (e.g. PQresultIsOutOrMemory()
or something similar) should be provided.
Regards,
Yugo Nagata
--
Yugo Nagata <nagata@sraoss.co.jp>
