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

Поиск
Список
Период
Сортировка
От Yugo Nagata
Тема Re: Make PQgetResult() not return NULL on out-of-memory error
Дата
Msg-id 20251112194640.362a06a7fada90201dfe5dad@sraoss.co.jp
обсуждение исходный текст
Ответ на Re: Make PQgetResult() not return NULL on out-of-memory error  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-hackers
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>



В списке pgsql-hackers по дате отправления: