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 по дате отправления: