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

From: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Make PQgetResult() not return NULL on out-of-memory error
Date: 2025-11-12 10:46:40
Message-ID: 20251112194640.362a06a7fada90201dfe5dad@sraoss.co.jp
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, 12 Nov 2025 18:09:28 +0900
Fujii Masao <masao(dot)fujii(at)gmail(dot)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(at)sraoss(dot)co(dot)jp>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2025-11-12 10:47:16 Re: Trying out read streams in pgvector (an extension)
Previous Message Masahiko Sawada 2025-11-12 10:06:19 Re: POC: enable logical decoding when wal_level = 'replica' without a server restart