From: Heikki Linnakangas <heikki.linnakangas@iki.fi>
To: pgsql-committers@lists.postgresql.org
Subject: pgsql: libpq: Handle OOM by disconnecting instead of hanging or skippin
Date: Fri, 22 Aug 2025 11:45:06 +0000
Message-ID: <E1upQCf-0017pS-1L@gemulon.postgresql.org> (raw)
libpq: Handle OOM by disconnecting instead of hanging or skipping msgs
In most cases, if an out-of-memory situation happens, we attach the
error message to the connection and report it at the next
PQgetResult() call. However, there are a few cases, while processing
messages that are not associated with any particular query, where we
handled failed allocations differently and not very nicely:
- If we ran out of memory while processing an async notification,
getNotify() either returned EOF, which stopped processing any
further data until more data was received from the server, or
silently dropped the notification. Returning EOF is problematic
because if more data never arrives, e.g. because the connection was
used just to wait for the notification, or because the next
ReadyForQuery was already received and buffered, it would get stuck
forever. Silently dropping a notification is not nice either.
- (New in v18) If we ran out of memory while receiving BackendKeyData
message, getBackendKeyData() returned EOF, which has the same issues
as in getNotify().
- If we ran out of memory while saving a received a ParameterStatus
message, we just skipped it. A later call to PQparameterStatus()
would return NULL, even though the server did send the status.
Change all those cases to terminate the connnection instead. Our
options for reporting those errors are limited, but it seems better to
terminate than try to soldier on. Applications should handle
connection loss gracefully, whereas silently missing a notification,
parameter status, or cancellation key could cause much weirder
problems.
This also changes the error message on OOM while expanding the input
buffer. It used to report "cannot allocate memory for input buffer",
followed by "lost synchronization with server: got message type ...".
The "lost synchronization" message seems unnecessary, so remove that
and report only "cannot allocate memory for input buffer". (The
comment speculated that the out of memory could indeed be caused by
loss of sync, but that seems highly unlikely.)
This evolved from a more narrow patch by Jelte Fennema-Nio, which was
reviewed by Jacob Champion.
Somewhat arbitrarily, backpatch to v18 but no further. These are
long-standing issues, but we haven't received any complaints from the
field. We can backpatch more later, if needed.
Co-authored-by: Jelte Fennema-Nio <postgres@jeltef.nl>
Reviewed-by: Jelte Fennema-Nio <postgres@jeltef.nl>
Reviewed-by: Jacob Champion <jchampion@postgresql.org>
Discussion: https://www.postgresql.org/message-id/df892f9f-5923-4046-9d6f-8c48d8980b50@iki.fi
Backpatch-through: 18
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/f6f0542266f0a04e94ac2a67ae6890d6095101ab
Modified Files
--------------
src/interfaces/libpq/fe-exec.c | 13 +++-
src/interfaces/libpq/fe-protocol3.c | 114 ++++++++++++++++++++++++------------
src/interfaces/libpq/libpq-int.h | 2 +-
3 files changed, 89 insertions(+), 40 deletions(-)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: heikki.linnakangas@iki.fi, pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: libpq: Handle OOM by disconnecting instead of hanging or skippin
In-Reply-To: <E1upQCf-0017pS-1L@gemulon.postgresql.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox