public inbox for [email protected]
help / color / mirror / Atom feedpgsql: libpq: Extend "read pending" check from SSL to GSS
7+ messages / 1 participants
[nested] [flat]
* pgsql: libpq: Extend "read pending" check from SSL to GSS
@ 2026-07-07 15:56 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 7+ messages in thread
From: Heikki Linnakangas @ 2026-07-07 15:56 UTC (permalink / raw)
To: [email protected]
libpq: Extend "read pending" check from SSL to GSS
An extra check for pending bytes in the SSL layer has been part of
pqReadReady() for a very long time (79ff2e96d). But when GSS transport
encryption was added, it didn't receive the same treatment. (As
79ff2e96d notes, "The bug that I fixed in this patch is exceptionally
hard to reproduce reliably.")
Without that check, it's possible to hit a hang in gssencmode, if the
server splits a large libpq message such that the final message in a
streamed response is part of the same wrapped token as the split
message:
DataRowDataRowDataRowDataRowDataRowData
-- token boundary --
RowDataRowCommandCompleteReadyForQuery
If the split message takes up enough memory to nearly fill libpq's
receive buffer, libpq may return from pqReadData() before the later
messages are pulled out of the PqGSSRecvBuffer. Without additional
socket activity from the server, pqReadReady() (via pqSocketCheck())
will never again return true, hanging the connection.
Pull the pending-bytes check into the pqsecure API layer, where both
SSL and GSS now implement it.
Note that this does not fix the root problem! Third party clients of
libpq have no way to call pqsecure_read_is_pending() in their own
polling. This just brings the GSS implementation up to par with the
existing SSL workaround; a broader fix is left to a subsequent commit.
In preparation for the broader fix, this patch already changes the
*_read_pending() functions to return the number of bytes in the buffer
rather than just a boolean. The current callers don't need that, but
the subsequent fix will.
Author: Jacob Champion <[email protected]>
Discussion: https://postgr.es/m/CAOYmi%2BmpymrgZ76Jre2dx_PwRniS9YZojwH0rZnTuiGHCsj0rA%40mail.gmail.com
Backpatch-through: 14
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/ffd080d94fe7154940a1bdac005390d0aee034bc
Modified Files
--------------
src/interfaces/libpq/fe-misc.c | 6 ++----
src/interfaces/libpq/fe-secure-gssapi.c | 7 +++++++
src/interfaces/libpq/fe-secure-openssl.c | 34 +++++++++++++++++++++++++++++---
src/interfaces/libpq/fe-secure.c | 22 +++++++++++++++++++++
src/interfaces/libpq/libpq-int.h | 6 ++++--
5 files changed, 66 insertions(+), 9 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: libpq: Extend "read pending" check from SSL to GSS
@ 2026-07-07 15:56 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 7+ messages in thread
From: Heikki Linnakangas @ 2026-07-07 15:56 UTC (permalink / raw)
To: [email protected]
libpq: Extend "read pending" check from SSL to GSS
An extra check for pending bytes in the SSL layer has been part of
pqReadReady() for a very long time (79ff2e96d). But when GSS transport
encryption was added, it didn't receive the same treatment. (As
79ff2e96d notes, "The bug that I fixed in this patch is exceptionally
hard to reproduce reliably.")
Without that check, it's possible to hit a hang in gssencmode, if the
server splits a large libpq message such that the final message in a
streamed response is part of the same wrapped token as the split
message:
DataRowDataRowDataRowDataRowDataRowData
-- token boundary --
RowDataRowCommandCompleteReadyForQuery
If the split message takes up enough memory to nearly fill libpq's
receive buffer, libpq may return from pqReadData() before the later
messages are pulled out of the PqGSSRecvBuffer. Without additional
socket activity from the server, pqReadReady() (via pqSocketCheck())
will never again return true, hanging the connection.
Pull the pending-bytes check into the pqsecure API layer, where both
SSL and GSS now implement it.
Note that this does not fix the root problem! Third party clients of
libpq have no way to call pqsecure_read_is_pending() in their own
polling. This just brings the GSS implementation up to par with the
existing SSL workaround; a broader fix is left to a subsequent commit.
In preparation for the broader fix, this patch already changes the
*_read_pending() functions to return the number of bytes in the buffer
rather than just a boolean. The current callers don't need that, but
the subsequent fix will.
Author: Jacob Champion <[email protected]>
Discussion: https://postgr.es/m/CAOYmi%2BmpymrgZ76Jre2dx_PwRniS9YZojwH0rZnTuiGHCsj0rA%40mail.gmail.com
Backpatch-through: 14
Branch
------
REL_19_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/eeb2940ae83cb6a5e48e90465bea0cede341ea59
Modified Files
--------------
src/interfaces/libpq/fe-misc.c | 6 ++----
src/interfaces/libpq/fe-secure-gssapi.c | 7 +++++++
src/interfaces/libpq/fe-secure-openssl.c | 34 +++++++++++++++++++++++++++++---
src/interfaces/libpq/fe-secure.c | 22 +++++++++++++++++++++
src/interfaces/libpq/libpq-int.h | 6 ++++--
5 files changed, 66 insertions(+), 9 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: libpq: Extend "read pending" check from SSL to GSS
@ 2026-07-07 15:56 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 7+ messages in thread
From: Heikki Linnakangas @ 2026-07-07 15:56 UTC (permalink / raw)
To: [email protected]
libpq: Extend "read pending" check from SSL to GSS
An extra check for pending bytes in the SSL layer has been part of
pqReadReady() for a very long time (79ff2e96d). But when GSS transport
encryption was added, it didn't receive the same treatment. (As
79ff2e96d notes, "The bug that I fixed in this patch is exceptionally
hard to reproduce reliably.")
Without that check, it's possible to hit a hang in gssencmode, if the
server splits a large libpq message such that the final message in a
streamed response is part of the same wrapped token as the split
message:
DataRowDataRowDataRowDataRowDataRowData
-- token boundary --
RowDataRowCommandCompleteReadyForQuery
If the split message takes up enough memory to nearly fill libpq's
receive buffer, libpq may return from pqReadData() before the later
messages are pulled out of the PqGSSRecvBuffer. Without additional
socket activity from the server, pqReadReady() (via pqSocketCheck())
will never again return true, hanging the connection.
Pull the pending-bytes check into the pqsecure API layer, where both
SSL and GSS now implement it.
Note that this does not fix the root problem! Third party clients of
libpq have no way to call pqsecure_read_is_pending() in their own
polling. This just brings the GSS implementation up to par with the
existing SSL workaround; a broader fix is left to a subsequent commit.
In preparation for the broader fix, this patch already changes the
*_read_pending() functions to return the number of bytes in the buffer
rather than just a boolean. The current callers don't need that, but
the subsequent fix will.
Author: Jacob Champion <[email protected]>
Discussion: https://postgr.es/m/CAOYmi%2BmpymrgZ76Jre2dx_PwRniS9YZojwH0rZnTuiGHCsj0rA%40mail.gmail.com
Backpatch-through: 14
Branch
------
REL_18_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/2167302b748fb8fa9112710014b50910b19b9f15
Modified Files
--------------
src/interfaces/libpq/fe-misc.c | 6 ++----
src/interfaces/libpq/fe-secure-gssapi.c | 7 +++++++
src/interfaces/libpq/fe-secure-openssl.c | 34 +++++++++++++++++++++++++++++---
src/interfaces/libpq/fe-secure.c | 22 +++++++++++++++++++++
src/interfaces/libpq/libpq-int.h | 6 ++++--
5 files changed, 66 insertions(+), 9 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: libpq: Extend "read pending" check from SSL to GSS
@ 2026-07-07 15:56 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 7+ messages in thread
From: Heikki Linnakangas @ 2026-07-07 15:56 UTC (permalink / raw)
To: [email protected]
libpq: Extend "read pending" check from SSL to GSS
An extra check for pending bytes in the SSL layer has been part of
pqReadReady() for a very long time (79ff2e96d). But when GSS transport
encryption was added, it didn't receive the same treatment. (As
79ff2e96d notes, "The bug that I fixed in this patch is exceptionally
hard to reproduce reliably.")
Without that check, it's possible to hit a hang in gssencmode, if the
server splits a large libpq message such that the final message in a
streamed response is part of the same wrapped token as the split
message:
DataRowDataRowDataRowDataRowDataRowData
-- token boundary --
RowDataRowCommandCompleteReadyForQuery
If the split message takes up enough memory to nearly fill libpq's
receive buffer, libpq may return from pqReadData() before the later
messages are pulled out of the PqGSSRecvBuffer. Without additional
socket activity from the server, pqReadReady() (via pqSocketCheck())
will never again return true, hanging the connection.
Pull the pending-bytes check into the pqsecure API layer, where both
SSL and GSS now implement it.
Note that this does not fix the root problem! Third party clients of
libpq have no way to call pqsecure_read_is_pending() in their own
polling. This just brings the GSS implementation up to par with the
existing SSL workaround; a broader fix is left to a subsequent commit.
In preparation for the broader fix, this patch already changes the
*_read_pending() functions to return the number of bytes in the buffer
rather than just a boolean. The current callers don't need that, but
the subsequent fix will.
Author: Jacob Champion <[email protected]>
Discussion: https://postgr.es/m/CAOYmi%2BmpymrgZ76Jre2dx_PwRniS9YZojwH0rZnTuiGHCsj0rA%40mail.gmail.com
Backpatch-through: 14
Branch
------
REL_17_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/c162810a503f15e536710f4c5c6dd80c85d6a7f4
Modified Files
--------------
src/interfaces/libpq/fe-misc.c | 6 ++----
src/interfaces/libpq/fe-secure-gssapi.c | 7 +++++++
src/interfaces/libpq/fe-secure-openssl.c | 34 +++++++++++++++++++++++++++++---
src/interfaces/libpq/fe-secure.c | 22 +++++++++++++++++++++
src/interfaces/libpq/libpq-int.h | 6 ++++--
5 files changed, 66 insertions(+), 9 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: libpq: Extend "read pending" check from SSL to GSS
@ 2026-07-07 15:56 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 7+ messages in thread
From: Heikki Linnakangas @ 2026-07-07 15:56 UTC (permalink / raw)
To: [email protected]
libpq: Extend "read pending" check from SSL to GSS
An extra check for pending bytes in the SSL layer has been part of
pqReadReady() for a very long time (79ff2e96d). But when GSS transport
encryption was added, it didn't receive the same treatment. (As
79ff2e96d notes, "The bug that I fixed in this patch is exceptionally
hard to reproduce reliably.")
Without that check, it's possible to hit a hang in gssencmode, if the
server splits a large libpq message such that the final message in a
streamed response is part of the same wrapped token as the split
message:
DataRowDataRowDataRowDataRowDataRowData
-- token boundary --
RowDataRowCommandCompleteReadyForQuery
If the split message takes up enough memory to nearly fill libpq's
receive buffer, libpq may return from pqReadData() before the later
messages are pulled out of the PqGSSRecvBuffer. Without additional
socket activity from the server, pqReadReady() (via pqSocketCheck())
will never again return true, hanging the connection.
Pull the pending-bytes check into the pqsecure API layer, where both
SSL and GSS now implement it.
Note that this does not fix the root problem! Third party clients of
libpq have no way to call pqsecure_read_is_pending() in their own
polling. This just brings the GSS implementation up to par with the
existing SSL workaround; a broader fix is left to a subsequent commit.
In preparation for the broader fix, this patch already changes the
*_read_pending() functions to return the number of bytes in the buffer
rather than just a boolean. The current callers don't need that, but
the subsequent fix will.
Author: Jacob Champion <[email protected]>
Discussion: https://postgr.es/m/CAOYmi%2BmpymrgZ76Jre2dx_PwRniS9YZojwH0rZnTuiGHCsj0rA%40mail.gmail.com
Backpatch-through: 14
Branch
------
REL_16_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/d3f329656cdceab148a0711aab266d91f4640be6
Modified Files
--------------
src/interfaces/libpq/fe-misc.c | 6 ++----
src/interfaces/libpq/fe-secure-gssapi.c | 7 +++++++
src/interfaces/libpq/fe-secure-openssl.c | 34 +++++++++++++++++++++++++++++---
src/interfaces/libpq/fe-secure.c | 22 +++++++++++++++++++++
src/interfaces/libpq/libpq-int.h | 6 ++++--
5 files changed, 66 insertions(+), 9 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: libpq: Extend "read pending" check from SSL to GSS
@ 2026-07-07 15:56 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 7+ messages in thread
From: Heikki Linnakangas @ 2026-07-07 15:56 UTC (permalink / raw)
To: [email protected]
libpq: Extend "read pending" check from SSL to GSS
An extra check for pending bytes in the SSL layer has been part of
pqReadReady() for a very long time (79ff2e96d). But when GSS transport
encryption was added, it didn't receive the same treatment. (As
79ff2e96d notes, "The bug that I fixed in this patch is exceptionally
hard to reproduce reliably.")
Without that check, it's possible to hit a hang in gssencmode, if the
server splits a large libpq message such that the final message in a
streamed response is part of the same wrapped token as the split
message:
DataRowDataRowDataRowDataRowDataRowData
-- token boundary --
RowDataRowCommandCompleteReadyForQuery
If the split message takes up enough memory to nearly fill libpq's
receive buffer, libpq may return from pqReadData() before the later
messages are pulled out of the PqGSSRecvBuffer. Without additional
socket activity from the server, pqReadReady() (via pqSocketCheck())
will never again return true, hanging the connection.
Pull the pending-bytes check into the pqsecure API layer, where both
SSL and GSS now implement it.
Note that this does not fix the root problem! Third party clients of
libpq have no way to call pqsecure_read_is_pending() in their own
polling. This just brings the GSS implementation up to par with the
existing SSL workaround; a broader fix is left to a subsequent commit.
In preparation for the broader fix, this patch already changes the
*_read_pending() functions to return the number of bytes in the buffer
rather than just a boolean. The current callers don't need that, but
the subsequent fix will.
Author: Jacob Champion <[email protected]>
Discussion: https://postgr.es/m/CAOYmi%2BmpymrgZ76Jre2dx_PwRniS9YZojwH0rZnTuiGHCsj0rA%40mail.gmail.com
Backpatch-through: 14
Branch
------
REL_15_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/4ecba7fa3a637badde33480284ac57f92d476f62
Modified Files
--------------
src/interfaces/libpq/fe-misc.c | 6 ++----
src/interfaces/libpq/fe-secure-gssapi.c | 7 +++++++
src/interfaces/libpq/fe-secure-openssl.c | 36 +++++++++++++++++++++++++++++---
src/interfaces/libpq/fe-secure.c | 22 +++++++++++++++++++
src/interfaces/libpq/libpq-int.h | 6 ++++--
5 files changed, 68 insertions(+), 9 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
* pgsql: libpq: Extend "read pending" check from SSL to GSS
@ 2026-07-07 15:56 Heikki Linnakangas <[email protected]>
0 siblings, 0 replies; 7+ messages in thread
From: Heikki Linnakangas @ 2026-07-07 15:56 UTC (permalink / raw)
To: [email protected]
libpq: Extend "read pending" check from SSL to GSS
An extra check for pending bytes in the SSL layer has been part of
pqReadReady() for a very long time (79ff2e96d). But when GSS transport
encryption was added, it didn't receive the same treatment. (As
79ff2e96d notes, "The bug that I fixed in this patch is exceptionally
hard to reproduce reliably.")
Without that check, it's possible to hit a hang in gssencmode, if the
server splits a large libpq message such that the final message in a
streamed response is part of the same wrapped token as the split
message:
DataRowDataRowDataRowDataRowDataRowData
-- token boundary --
RowDataRowCommandCompleteReadyForQuery
If the split message takes up enough memory to nearly fill libpq's
receive buffer, libpq may return from pqReadData() before the later
messages are pulled out of the PqGSSRecvBuffer. Without additional
socket activity from the server, pqReadReady() (via pqSocketCheck())
will never again return true, hanging the connection.
Pull the pending-bytes check into the pqsecure API layer, where both
SSL and GSS now implement it.
Note that this does not fix the root problem! Third party clients of
libpq have no way to call pqsecure_read_is_pending() in their own
polling. This just brings the GSS implementation up to par with the
existing SSL workaround; a broader fix is left to a subsequent commit.
In preparation for the broader fix, this patch already changes the
*_read_pending() functions to return the number of bytes in the buffer
rather than just a boolean. The current callers don't need that, but
the subsequent fix will.
Author: Jacob Champion <[email protected]>
Discussion: https://postgr.es/m/CAOYmi%2BmpymrgZ76Jre2dx_PwRniS9YZojwH0rZnTuiGHCsj0rA%40mail.gmail.com
Backpatch-through: 14
Branch
------
REL_14_STABLE
Details
-------
https://git.postgresql.org/pg/commitdiff/1b018b5d10561a49fcd987a0a659ec06fbd6ee8f
Modified Files
--------------
src/interfaces/libpq/fe-misc.c | 6 ++----
src/interfaces/libpq/fe-secure-gssapi.c | 7 +++++++
src/interfaces/libpq/fe-secure-openssl.c | 36 +++++++++++++++++++++++++++++---
src/interfaces/libpq/fe-secure.c | 22 +++++++++++++++++++
src/interfaces/libpq/libpq-int.h | 6 ++++--
5 files changed, 68 insertions(+), 9 deletions(-)
^ permalink raw reply [nested|flat] 7+ messages in thread
end of thread, other threads:[~2026-07-07 15:56 UTC | newest]
Thread overview: 7+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-07-07 15:56 pgsql: libpq: Extend "read pending" check from SSL to GSS Heikki Linnakangas <[email protected]>
2026-07-07 15:56 pgsql: libpq: Extend "read pending" check from SSL to GSS Heikki Linnakangas <[email protected]>
2026-07-07 15:56 pgsql: libpq: Extend "read pending" check from SSL to GSS Heikki Linnakangas <[email protected]>
2026-07-07 15:56 pgsql: libpq: Extend "read pending" check from SSL to GSS Heikki Linnakangas <[email protected]>
2026-07-07 15:56 pgsql: libpq: Extend "read pending" check from SSL to GSS Heikki Linnakangas <[email protected]>
2026-07-07 15:56 pgsql: libpq: Extend "read pending" check from SSL to GSS Heikki Linnakangas <[email protected]>
2026-07-07 15:56 pgsql: libpq: Extend "read pending" check from SSL to GSS Heikki Linnakangas <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox