Skip to content
Permalink

Comparing changes

Choose two branches to see what’s changed or to start a new pull request. If you need to, you can also or learn more about diff comparisons.

Open a pull request

Create a new pull request by comparing changes across two branches. If you need to, you can also . Learn more about diff comparisons here.
base repository: postgresql-cfbot/postgresql
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: cf/5859~1
Choose a base ref
...
head repository: postgresql-cfbot/postgresql
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: cf/5859
Choose a head ref
  • 4 commits
  • 4 files changed
  • 2 contributors

Commits on Aug 22, 2025

  1. libpq: Don't hang on out-of-memory 

    If an allocation failed while handling an async notification, we
returned EOF, which stopped processing any further data until more
data was received from the server. 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. Instead, silently ignore the
notification.

Silently ignoring the notification is not a great way to handle the
situation, but at least the connection doesn't get stuck, and it's
consistent with how the malloc() later in the function is handled, and
with e.g. how pqSaveParameterStatus() handles allocation failures.

Fix the same issue with OOM on receiving BackendKeyData message. That
one is new in v18.

Discussion: https://www.postgresql.org/message-id/[email protected]
    @hlinnaka
    hlinnaka authored and Commitfest Bot committed Aug 22, 2025
    Configuration menu
    Copy the full SHA
    849a611 View commit details
    Browse the repository at this point in the history

  2. libpq: Handle OOMs by disconnecting instead of silently skipping mess… 

    …ages

As noted in the previous commit, silently ignoring async notifications
is not great. Our options for reporting errors are limited, but it
seems better to terminate the connection than try to soldier
on. Applications should handle connection loss gracefully, whereas
silently missing a notification could cause much weirder problems.

Similarly, if we run out of memory while saving a received
ParameterStatus or cancellation key, disconnect.

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.)

Discussion: https://www.postgresql.org/message-id/[email protected]
    @hlinnaka
    hlinnaka authored and Commitfest Bot committed Aug 22, 2025
    Configuration menu
    Copy the full SHA
    281757d View commit details
    Browse the repository at this point in the history

  3. libpq: Be strict about cancel key lengths 

    The protocol documentation states that the maximum length of a cancel
key is 256 bytes. This starts checking for that limit in
libpq. Otherwise third party backend implementations will probably
start using more bytes anyway. We also start requiring that a protocol
3.0 connection does not send a longer cancel key, to make sure that
servers don't start breaking old 3.0-only clients by accident. Finally
this also restricts the minimum key length to 4 bytes (both in the
protocol spec and in the libpq implementation).

Author: Jelte Fennema-Nio <[email protected]>
Discussion: https://www.postgresql.org/message-id/[email protected]
    @hlinnaka
    hlinnaka authored and Commitfest Bot committed Aug 22, 2025
    Configuration menu
    Copy the full SHA
    00e2825 View commit details
    Browse the repository at this point in the history

  4. [CF 5859] v4 - Allow missing BackendKeyData message & enforce cancel … 

    …key length

This branch was automatically generated by a robot using patches from an
email thread registered at:

https://commitfest.postgresql.org/patch/5859

The branch will be overwritten each time a new patch version is posted to
the thread, and also periodically to check for bitrot caused by changes
on the master branch.

Patch(es): https://www.postgresql.org/message-id/[email protected]
Author(s): Jelte Fennema-Nio
    Commitfest Bot committed Aug 22, 2025
    Configuration menu
    Copy the full SHA
    f531701 View commit details
    Browse the repository at this point in the history
Loading