On Wed, 12 Nov 2025 18:09:28 +0900 Fujii Masao <[email protected]> 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 <[email protected]>
