Base de données relationnelle
Find a file
Heikki Linnakangas 477bc27a59 libpq: Drain all pending bytes from SSL/GSS during pqReadData()
The previous commit strengthened a workaround for a hang when large
messages are split across TLS records/GSS tokens. Because that
workaround is implemented in libpq internals, it can only help us when
libpq itself is polling on the socket. In nonblocking situations,
where the client above libpq is expected to poll, the same bugs can
show up.

As a contrived example, consider a large protocol-2.0 error coming
back from a server during PQconnectPoll(), split in an odd way across
two records:

    -- TLS record (8192-byte payload) --
    EEEE[...repeated a total of 8192 times]
    -- TLS record (8193-byte payload) --
    EEEE[...repeated a total of 8192 times]\0

The first record will fill the first half of the libpq receive buffer,
which is 16k long by default. The second record completely fills the
last half with its first 8192 bytes, leaving the terminating NULL in
the OpenSSL buffer. Since we still haven't seen the terminator at our
level, PQconnectPoll() will return PGRES_POLLING_READING, expecting to
come back when the server has sent "the rest" of the data.  But there
is nothing left to read from the socket; OpenSSL had to pull all of
the data in the 8193-byte record off of the wire to decrypt it.

A real server would probably not split up the records this way, nor
keep the connection open after sending a fatal connection error. But
servers that regularly use larger TLS records can get the libpq
receive buffer into the same state if DataRows are big enough, as
reported on the list. While the PostgreSQL server doesn't use larger
TLS records like that, other non-PostgreSQL servers that implement the
wire protocol are known to do that, as well as proxies that sit
between the server and the client

This is a layering violation. libpq makes decisions based on data in
the application buffer, above the transport buffer (whether SSL or
GSS), but clients are polling the socket below the transport buffer.
One way to fix this in a backportable way, without changing APIs too
much, is to ensure data never stays in the transport buffer. Then
pqReadData's postconditions will look similar for both raw sockets and
SSL/GSS: any available data is either in the application buffer, or
still on the socket.

Building on the prior commit, make pqReadData() to drain all pending
data from the transport layer into conn->inBuffer, expanding the
buffer as necessary. This is not particularly efficient from an
architectural perspective (the pqsecure_read() implementations take
care to fit their packets into the current buffer, and that effort is
now completely discarded), but it's hopefully easier to reason about
than a full rewrite would be for the back branches.

Author: Jacob Champion <jacob.champion@enterprisedb.com>
Reviewed-by: Mark Dilger <mark.dilger@enterprisedb.com>
Reviewed-by: solai v <solai.cdac@gmail.com>
Reported-by: Lars Kanis <lars@greiz-reinsdorf.de>
Discussion: https://postgr.es/m/2039ac58-d3e0-434b-ac1a-2a987f3b4cb1%40greiz-reinsdorf.de
Backpatch-through: 14
2026-07-07 18:47:07 +03:00
config Allow PG_PRINTF_ATTRIBUTE to be different in C and C++ code. 2026-02-25 11:57:26 -05:00
contrib Fix btree_gist's NotEqual strategy on internal index pages. 2026-07-03 13:50:14 -04:00
doc Remove replication slot advice from MultiXact wraparound hints 2026-07-03 11:21:10 +09:00
src libpq: Drain all pending bytes from SSL/GSS during pqReadData() 2026-07-07 18:47:07 +03:00
.abi-compliance-history Re-introduce pgstat_drop_entry(), keeping ABI compatibility 2026-06-23 07:59:02 +09:00
.cirrus.star ci: Simplify ci-os-only handling 2025-08-14 12:03:27 -04:00
.cirrus.tasks.yml Make stack depth check work with asan's use-after-return 2026-05-28 11:34:13 -04:00
.cirrus.yml ci: Per-repo configuration for manually trigger tasks 2025-08-14 11:33:50 -04:00
.dir-locals.el Make Emacs perl-mode indent more like perltidy. 2019-01-13 11:32:31 -08:00
.editorconfig Add .editorconfig 2019-12-18 09:13:13 +01:00
.git-blame-ignore-revs Add previous commit to .git-blame-ignore-revs. 2025-10-21 10:02:19 -05:00
.gitattributes Fix git whitespace warning 2025-08-15 10:31:52 +02:00
.gitignore Update top-level .gitignore. 2022-12-04 15:23:00 -05:00
aclocal.m4 autoconf: Move export_dynamic determination to configure 2022-12-06 18:55:28 -08:00
configure Stamp 16.14. 2026-05-11 15:48:18 -04:00
configure.ac Stamp 16.14. 2026-05-11 15:48:18 -04:00
COPYRIGHT Update copyright for 2026 2026-01-01 13:24:10 -05:00
GNUmakefile.in Integrate pg_bsd_indent into our build/test infrastructure. 2023-02-12 12:22:21 -05:00
HISTORY Canonicalize some URLs 2020-02-10 20:47:50 +01:00
Makefile Dynamically find correct installation docs in Makefile. 2022-01-19 14:48:25 +01:00
meson.build Stamp 16.14. 2026-05-11 15:48:18 -04:00
meson_options.txt meson: Attach colon to keyword argument 2023-06-29 12:53:41 +02:00
README Canonicalize some URLs 2020-02-10 20:47:50 +01:00
README.git Canonicalize some URLs 2020-02-10 20:47:50 +01:00

PostgreSQL Database Management System
=====================================

This directory contains the source code distribution of the PostgreSQL
database management system.

PostgreSQL is an advanced object-relational database management system
that supports an extended subset of the SQL standard, including
transactions, foreign keys, subqueries, triggers, user-defined types
and functions.  This distribution also contains C language bindings.

PostgreSQL has many language interfaces, many of which are listed here:

	https://www.postgresql.org/download/

See the file INSTALL for instructions on how to build and install
PostgreSQL.  That file also lists supported operating systems and
hardware platforms and contains information regarding any other
software packages that are required to build or run the PostgreSQL
system.  Copyright and license information can be found in the
file COPYRIGHT.  A comprehensive documentation set is included in this
distribution; it can be read as described in the installation
instructions.

The latest version of this software may be obtained at
https://www.postgresql.org/download/.  For more information look at our
web site located at https://www.postgresql.org/.