pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq
8+ messages / 4 participants
[nested] [flat]
* BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq
@ 2025-04-29 16:35 PG Bug reporting form <noreply@postgresql.org>
2025-04-29 18:06 ` Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 8+ messages in thread
From: PG Bug reporting form @ 2025-04-29 16:35 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: htgn.dbat.95@gmail.com
The following bug has been logged on the website:
Bug reference: 18907
Logged by: Dorjpalam Batbaatar
Email address: htgn.dbat.95@gmail.com
PostgreSQL version: 16.4
Operating system: AlmaLinux 9
Description:
When using libpq to transfer large amounts of data to the server in pipeline
mode (registering with COPY), an error "SSL error: bad length"
sometimes occurs. The most common cause of the error is libpq's
PQsendQueryParams(). PostgreSQL is version 16.4.
I looked into this here, and it seems that the cause is that openssl's
SSL_write() is not being retried when it should be.
According to the openssl documentation SSL_write(), if the return value of
SSL_get_error() is SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE,
it must be called again with the same data.
https://docs.openssl.org/3.0/man3/SSL_write/#warnings
In libpq's message sending function pqPutMsgEnd(PGconn *conn), if not all
data has been sent and in non-blocking mode, it just returns,
but in the libpq's exported API (e.g. PQsendQueryGuts() called by
PQsendQueryParams()), pqPutMsgEnd() is called multiple times, so I think the
sent data changes.
So in the above situation, it needs to be retried with the same data, but it
seems that the error occurs because the send data has changed.
As a test, I tried to retry if pqsecure_write() returned 0 in pqSendSome(),
and it ran in pipeline mode without errors. pqSendSome()
is a function which called from pqPutMsgEnd(PGconn *conn) and
pqsecure_write() is called from this. In pqsecure_write() SSL_write() is
performed.
Below is the patch I tried.
diff --git a/src/interfaces/libpq/fe-misc.c b/src/interfaces/libpq/fe-misc.c
index 488f7d6e55..bbafb189c9 100644
--- a/src/interfaces/libpq/fe-misc.c
+++ b/src/interfaces/libpq/fe-misc.c
@@ -914,22 +914,43 @@ pqSendSome(PGconn *conn, int len)
* Note that errors here don't result in
write_failed becoming
* set.
*/
- if (pqReadData(conn) < 0)
+ if (sent > 0)
{
- result = -1; /* error message already set
up */
- break;
- }
+ if (pqReadData(conn) < 0)
+ {
+ result = -1; /* error message
already set up */
+ break;
+ }
- if (pqIsnonblocking(conn))
- {
- result = 1;
- break;
- }
+ if (pqIsnonblocking(conn))
+ {
+ result = 1;
+ break;
+ }
- if (pqWait(true, true, conn))
+ if (pqWait(true, true, conn))
+ {
+ result = -1;
+ break;
+ }
+ }
+ else
{
- result = -1;
- break;
+ /*
+ * When sent is 0 retry for write. Before
write again read
+ * which arrived responses from the server
+ */
+ if (pqWait(true, true, conn))
+ {
+ result = -1;
+ break;
+ }
+
+ if (pqReadData(conn) < 0)
+ {
+ result = -1; /* error message
already set up */
+ break;
+ }
}
}
}
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq
2025-04-29 16:35 BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq PG Bug reporting form <noreply@postgresql.org>
@ 2025-04-29 18:06 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-04-29 18:48 ` Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq Jacob Champion <jacob.champion@enterprisedb.com>
0 siblings, 1 reply; 8+ messages in thread
From: Tom Lane @ 2025-04-29 18:06 UTC (permalink / raw)
To: htgn.dbat.95@gmail.com; +Cc: pgsql-bugs@lists.postgresql.org
PG Bug reporting form <noreply@postgresql.org> writes:
> When using libpq to transfer large amounts of data to the server in pipeline
> mode (registering with COPY), an error "SSL error: bad length"
> sometimes occurs.
Could you provide a self-contained test case demonstrating such
failures? This is not the kind of code that we like to change
on the basis of undocumented claims.
regards, tom lane
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq
2025-04-29 16:35 BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq PG Bug reporting form <noreply@postgresql.org>
2025-04-29 18:06 ` Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq Tom Lane <tgl@sss.pgh.pa.us>
@ 2025-04-29 18:48 ` Jacob Champion <jacob.champion@enterprisedb.com>
2025-06-07 05:01 ` Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq BATBAATAR Dorjpalam <htgn.dbat.95@gmail.com>
0 siblings, 1 reply; 8+ messages in thread
From: Jacob Champion @ 2025-04-29 18:48 UTC (permalink / raw)
To: htgn.dbat.95@gmail.com; +Cc: pgsql-bugs@lists.postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
On Tue, Apr 29, 2025 at 11:06 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Could you provide a self-contained test case demonstrating such
> failures? This is not the kind of code that we like to change
> on the basis of undocumented claims.
Agreed -- but also, let us know if the answer is "no, I can't", or if
you get stuck and need some additional collaboration. These corner
cases can be really nasty to track down and record.
Thanks,
--Jacob
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq
2025-04-29 16:35 BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq PG Bug reporting form <noreply@postgresql.org>
2025-04-29 18:06 ` Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq Tom Lane <tgl@sss.pgh.pa.us>
2025-04-29 18:48 ` Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq Jacob Champion <jacob.champion@enterprisedb.com>
@ 2025-06-07 05:01 ` BATBAATAR Dorjpalam <htgn.dbat.95@gmail.com>
2025-06-09 14:26 ` Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 8+ messages in thread
From: BATBAATAR Dorjpalam @ 2025-06-07 05:01 UTC (permalink / raw)
To: Jacob Champion <jacob.champion@enterprisedb.com>; +Cc: pgsql-bugs@lists.postgresql.org, Tom Lane <tgl@sss.pgh.pa.us>
I am sending a sample program to reproduce the this phenomenon.
The attached archive contains a Makefile to build with PostgreSQL17.
To run the program, all you need is a PostgreSQL17 server with SSL
connection.
After building, you will have an executable file named
query-data-send-error.
Please execute it as follows.
./query-data-send-error -i 200 -u 200 -c
"postgres://postgres:postgres@192.168.0.10/postgres?sslmode=require"
The -i is the number of times to create a test data record,
-u is the number of times to update the test data record,
-c specifies the connection string of the PostgreSQL server to connect to,
respectively.
The sample program does the following
1) Create the test_data table.
2) Register test data in units of 100 records for the number of times
specified by -i.
3) Repeat updating the registered records for the number of times
specified by -u.
My environment is as follows
PostgreSQL Server: 17.2
OS: Rocky Linux 9.5 (Blue Onyx)
Kernel: Linux 5.14.0-503.22.1.el9_5.x86_64
Spec: CPU 4vCore/Memory 8G/HDD 400G
At runtime, the following error occurs when updating.
Line : 552
SSL error: bad length
SSL SYSCALL error: EOF detected
Depending on the timing, this error may not occur, but if the number of
times is increased, will occur almost every time.
On 2025/04/30 3:48, Jacob Champion wrote:
> On Tue, Apr 29, 2025 at 11:06 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Could you provide a self-contained test case demonstrating such
>> failures? This is not the kind of code that we like to change
>> on the basis of undocumented claims.
> Agreed -- but also, let us know if the answer is "no, I can't", or if
> you get stuck and need some additional collaboration. These corner
> cases can be really nasty to track down and record.
>
> Thanks,
> --Jacob
Attachments:
[application/x-compressed] query-data-send-error.tgz (4.3K, ../../1ba0f64a-9f35-4fb4-83b0-6c11a1b88740@gmail.com/2-query-data-send-error.tgz)
download
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq
2025-04-29 16:35 BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq PG Bug reporting form <noreply@postgresql.org>
2025-04-29 18:06 ` Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq Tom Lane <tgl@sss.pgh.pa.us>
2025-04-29 18:48 ` Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq Jacob Champion <jacob.champion@enterprisedb.com>
2025-06-07 05:01 ` Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq BATBAATAR Dorjpalam <htgn.dbat.95@gmail.com>
@ 2025-06-09 14:26 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-06-09 17:02 ` Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 8+ messages in thread
From: Tom Lane @ 2025-06-09 14:26 UTC (permalink / raw)
To: BATBAATAR Dorjpalam <htgn.dbat.95@gmail.com>; +Cc: Jacob Champion <jacob.champion@enterprisedb.com>; pgsql-bugs@lists.postgresql.org
BATBAATAR Dorjpalam <htgn.dbat.95@gmail.com> writes:
> I am sending a sample program to reproduce the this phenomenon.
Thank you for the reproducer! (For anyone following along at home,
it doesn't fail for me with the suggested "-i 200 -u 200" parameters,
but it does fail in most runs with "-i 1000 -u 200".)
After some playing around, I figured out that the trouble scenario
is like this:
* We have a bunch of data pending to be sent, and we try to pqFlush()
it. OpenSSL returns SSL_WANT_WRITE, and since we're in nonblock mode
we just accept the failure-to-write and continue on.
* The app provides a bit more data to be sent, and we get to
pqPutMsgEnd(), which does this:
if (conn->outCount >= 8192)
{
int toSend = conn->outCount - (conn->outCount % 8192);
if (pqSendSome(conn, toSend) < 0)
return EOF;
/* in nonblock mode, don't complain if unable to send it all */
}
Because of rounding toSend down to an 8K multiple, we are asking
OpenSSL to send less than the previous pqFlush call asked to send.
That violates the SSL_write() API, and at least some of the time
it results in SSL_R_BAD_LENGTH.
As a quick cross-check I've been running with
diff --git a/src/interfaces/libpq/fe-misc.c b/src/interfaces/libpq/fe-misc.c
index c14e3c95250..75593ef0f72 100644
--- a/src/interfaces/libpq/fe-misc.c
+++ b/src/interfaces/libpq/fe-misc.c
@@ -555,7 +555,7 @@ pqPutMsgEnd(PGconn *conn)
if (conn->outCount >= 8192)
{
- int toSend = conn->outCount - (conn->outCount % 8192);
+ int toSend = conn->outCount;
if (pqSendSome(conn, toSend) < 0)
return EOF;
and that seems to prevent the failure.
The SSL_write docs say that you should not either increase or
decrease the length during a repeat call after SSL_WANT_WRITE,
but that seems to be a lie: increasing the length doesn't cause
any problems. (We do use SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER,
and perhaps that affects this?)
For a real fix, the narrowest answer would be to not round down
toSend if we are using an SSL connection. I wonder though if
the round-down behavior is of any use with GSSAPI either, or
more generally if it's sensible for anything except a Unix-pipe
connection.
regards, tom lane
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq
2025-04-29 16:35 BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq PG Bug reporting form <noreply@postgresql.org>
2025-04-29 18:06 ` Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq Tom Lane <tgl@sss.pgh.pa.us>
2025-04-29 18:48 ` Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq Jacob Champion <jacob.champion@enterprisedb.com>
2025-06-07 05:01 ` Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq BATBAATAR Dorjpalam <htgn.dbat.95@gmail.com>
2025-06-09 14:26 ` Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq Tom Lane <tgl@sss.pgh.pa.us>
@ 2025-06-09 17:02 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-06-10 00:40 ` Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 8+ messages in thread
From: Tom Lane @ 2025-06-09 17:02 UTC (permalink / raw)
To: Jacob Champion <jacob.champion@enterprisedb.com>; +Cc: BATBAATAR Dorjpalam <htgn.dbat.95@gmail.com>; pgsql-bugs@lists.postgresql.org
I wrote:
> For a real fix, the narrowest answer would be to not round down
> toSend if we are using an SSL connection. I wonder though if
> the round-down behavior is of any use with GSSAPI either, or
> more generally if it's sensible for anything except a Unix-pipe
> connection.
Indeed, it looks like we'd better disable the round-down for GSSAPI
too, because pg_GSS_write has exactly this same API requirement that
caller has to pass at least as much data as last time.
Interestingly, we got a report of such a failure with GSSAPI
awhile ago, and "fixed" it in commit d053a879b. Apparently
the test case we were looking at then did not trigger this
specific pattern involving pqFlush followed by pqPutMsgEnd,
because that commit did not do anything to prevent this
failure pattern.
I'm disinclined to revert what d053a879b did, but we'd better
remove or update this comment:
+ * Note: it may seem attractive to report partial write completion once
+ * we've successfully sent any encrypted packets. However, that can cause
+ * problems for callers; notably, pqPutMsgEnd's heuristic to send only
+ * full 8K blocks interacts badly with such a hack. We won't save much,
+ * typically, by letting callers discard data early, so don't risk it.
regards, tom lane
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq
2025-04-29 16:35 BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq PG Bug reporting form <noreply@postgresql.org>
2025-04-29 18:06 ` Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq Tom Lane <tgl@sss.pgh.pa.us>
2025-04-29 18:48 ` Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq Jacob Champion <jacob.champion@enterprisedb.com>
2025-06-07 05:01 ` Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq BATBAATAR Dorjpalam <htgn.dbat.95@gmail.com>
2025-06-09 14:26 ` Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq Tom Lane <tgl@sss.pgh.pa.us>
2025-06-09 17:02 ` Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq Tom Lane <tgl@sss.pgh.pa.us>
@ 2025-06-10 00:40 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 8+ messages in thread
From: Tom Lane @ 2025-06-10 00:40 UTC (permalink / raw)
To: Jacob Champion <jacob.champion@enterprisedb.com>; +Cc: BATBAATAR Dorjpalam <htgn.dbat.95@gmail.com>; pgsql-bugs@lists.postgresql.org
I wrote:
> Indeed, it looks like we'd better disable the round-down for GSSAPI
> too, because pg_GSS_write has exactly this same API requirement that
> caller has to pass at least as much data as last time.
So in short, I propose the attached patch. I chose to disable the
round-down behavior for all TCP connections, including ones that
use neither SSL nor GSSAPI. I'm not sure if it's worth worrying
too much about that case.
regards, tom lane
Attachments:
[text/x-diff] v1-fix-bug-18907.patch (3.5K, ../../652538.1749516038@sss.pgh.pa.us/2-v1-fix-bug-18907.patch)
download | inline diff:
diff --git a/src/backend/libpq/be-secure-gssapi.c b/src/backend/libpq/be-secure-gssapi.c
index 3534f0b8111..5d98c58ffa8 100644
--- a/src/backend/libpq/be-secure-gssapi.c
+++ b/src/backend/libpq/be-secure-gssapi.c
@@ -121,9 +121,9 @@ be_gssapi_write(Port *port, const void *ptr, size_t len)
* again, so if it offers a len less than that, something is wrong.
*
* Note: it may seem attractive to report partial write completion once
- * we've successfully sent any encrypted packets. However, that can cause
- * problems for callers; notably, pqPutMsgEnd's heuristic to send only
- * full 8K blocks interacts badly with such a hack. We won't save much,
+ * we've successfully sent any encrypted packets. However, doing that
+ * expands the state space of this processing and has been responsible for
+ * bugs in the past (cf. commit d053a879b). We won't save much,
* typically, by letting callers discard data early, so don't risk it.
*/
if (len < PqGSSSendConsumed)
diff --git a/src/interfaces/libpq/fe-misc.c b/src/interfaces/libpq/fe-misc.c
index c14e3c95250..dca44fdc5d2 100644
--- a/src/interfaces/libpq/fe-misc.c
+++ b/src/interfaces/libpq/fe-misc.c
@@ -553,9 +553,35 @@ pqPutMsgEnd(PGconn *conn)
/* Make message eligible to send */
conn->outCount = conn->outMsgEnd;
+ /* If appropriate, try to push out some data */
if (conn->outCount >= 8192)
{
- int toSend = conn->outCount - (conn->outCount % 8192);
+ int toSend = conn->outCount;
+
+ /*
+ * On Unix-pipe connections, it seems profitable to prefer sending
+ * pipe-buffer-sized packets not randomly-sized ones, so retain the
+ * last partial-8K chunk in our buffer for now. On TCP connections,
+ * the advantage of that is far less clear. Moreover, it flat out
+ * isn't safe when using SSL or GSSAPI, because those code paths have
+ * API stipulations that if they fail to send all the data that was
+ * offered in the previous write attempt, we mustn't offer less data
+ * in this write attempt. The previous write attempt might've been
+ * pqFlush attempting to send everything in the buffer, so we mustn't
+ * offer less now. (Presently, we won't try to use SSL or GSSAPI on
+ * Unix connections, so those checks are just Asserts. They'll have
+ * to become part of the regular if-test if we ever change that.)
+ */
+ if (conn->raddr.addr.ss_family == AF_UNIX)
+ {
+#ifdef USE_SSL
+ Assert(!conn->ssl_in_use);
+#endif
+#ifdef ENABLE_GSS
+ Assert(!conn->gssenc);
+#endif
+ toSend -= toSend % 8192;
+ }
if (pqSendSome(conn, toSend) < 0)
return EOF;
diff --git a/src/interfaces/libpq/fe-secure-gssapi.c b/src/interfaces/libpq/fe-secure-gssapi.c
index 62d05f68496..bc9e1ce06fa 100644
--- a/src/interfaces/libpq/fe-secure-gssapi.c
+++ b/src/interfaces/libpq/fe-secure-gssapi.c
@@ -112,9 +112,9 @@ pg_GSS_write(PGconn *conn, const void *ptr, size_t len)
* again, so if it offers a len less than that, something is wrong.
*
* Note: it may seem attractive to report partial write completion once
- * we've successfully sent any encrypted packets. However, that can cause
- * problems for callers; notably, pqPutMsgEnd's heuristic to send only
- * full 8K blocks interacts badly with such a hack. We won't save much,
+ * we've successfully sent any encrypted packets. However, doing that
+ * expands the state space of this processing and has been responsible for
+ * bugs in the past (cf. commit d053a879b). We won't save much,
* typically, by letting callers discard data early, so don't risk it.
*/
if (len < PqGSSSendConsumed)
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq
@ 2025-06-07 07:20 BATBAATAR Dorjpalam <htgn.dbat.95@gmail.com>
0 siblings, 0 replies; 8+ messages in thread
From: BATBAATAR Dorjpalam @ 2025-06-07 07:20 UTC (permalink / raw)
To: Champion Jacob <jacob.champion@enterprisedb.com>; +Cc: pgsql-bugs@lists.postgresql.org, Lane Tom <tgl@sss.pgh.pa.us>
--Apple-Mail-DDE01288-E681-4DEB-9F9F-3E33446FF276
Content-Type: multipart/mixed;
boundary=Apple-Mail-9E672DF7-4C59-404C-80BA-CE751EA3EDF0
Content-Transfer-Encoding: 7bit
--Apple-Mail-9E672DF7-4C59-404C-80BA-CE751EA3EDF0
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=3D=
utf-8"></head><body dir=3D"auto"><div dir=3D"ltr">=EF=BB=BF
=20
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8"=
>
=20
=20
<br>
<br>
<div class=3D"moz-cite-prefix">On 2025/04/30 3:48, Jacob Champion
wrote:<br>
</div>
<blockquote type=3D"cite" cite=3D"mid:CAOYmi+kPBjLcHqbY1PK2bnvVJ90dBbJAp=
0vBfrDNHTdmscxvbg@mail.gmail.com">
<pre wrap=3D"" class=3D"moz-quote-pre">On Tue, Apr 29, 2025 at 11:06=E2=
=80=AFAM Tom Lane <a class=3D"moz-txt-link-rfc2396E" href=3D"mailto:tgl@sss.=
pgh.pa.us"><tgl@sss.pgh.pa.us></a> wrote:
</pre>
<blockquote type=3D"cite">
<pre wrap=3D"" class=3D"moz-quote-pre">Could you provide a self-cont=
ained test case demonstrating such
failures? This is not the kind of code that we like to change
on the basis of undocumented claims.
</pre>
</blockquote>
<pre wrap=3D"" class=3D"moz-quote-pre">Agreed -- but also, let us know=
if the answer is "no, I can't", or if
you get stuck and need some additional collaboration. These corner
cases can be really nasty to track down and record.
Thanks,
--Jacob
</pre>
</blockquote>
<br>
=20
</div></body></html>=
--Apple-Mail-9E672DF7-4C59-404C-80BA-CE751EA3EDF0
Content-Type: application/octet-stream;
name=query-data-send-error.tgz;
x-apple-part-url=F861D0F8-2EC2-4D8A-803A-99B3012A55D4
Content-Disposition: attachment;
filename=query-data-send-error.tgz
Content-Transfer-Encoding: base64
H4sIAAAAAAAAA+0b/XfaRjK/wl+x4WgKDmBkO192aGs72OWKAQNum+vl8WSxgM5CwpIIdVv/7zez
H9KuBDYkae/1HXovkdidnZ2d751d386pf1cemqFZDqg7LFPf9/yK9eRLPlV4Xh4csDc8iff+gbG/
98R4Ud2rvtp/ubdvPKkaB9UXB09I9YtSseKZB6HpE/LE97zwIbjH+v+mzz9s13LmQ0reBuHQsa8r
k2+ycVtoT6neMndtANTboMH29KaZ5zjYojUF4dinQRKQtw5GiYmAltltmbdmLc8NQmJNQFI7p+1W
q37ab7Rbg16/S2okJ3Ec7u5Gn/LjO+PVXmW/WjmovHoZ9X4bBM7UG9KaT2/ntk9zR2IG2w1J57h7
fDE4bV+1+oDcMNS+RqtX7/YH3fZPMUC1qkJcHP886NUveYfe9eNxc3BydTbo/Qt69/fUrnf1s+Or
Zn8g8Dfb7c6qCSToVefdcb++BDQbhP7cCsnQN93hwesB2rb2Y3A9H42oD/C/kyq5hxEfPXtIYNip
GRY4k3fC6ax365RIYP9GByHZCX4rCf7D6OIRH2IOh11v0TF9cxoUkDjfW0iwJRhgGO+zfGqGtOEG
1A8v0QHJwa359Jr6AIe/VSgxh0A9w18/ms6cBiXGlJ2A3mqjrmawUvrIKD6IrWQC7HFoywvtkW2Z
oQ3sLnTOgesu2ZmNT+ENkNee5xA76NJgBv20fQMgoE1zBwjgbwlkOdT0u6xpFZ7gzrU69ow6tkvT
IIyomQ9UdsZ1dMkJkBKJp56Nu2JBiCtiYXZ3h1zQqQfuHUVAzIXpU5Sy7Y4J4IJlUpctlezsbq4C
2d+zBB7R6VD3HShoDVHAd0EMBjJ0oJ5vxUBckxiEPSKFgkDyXAAWyTc1pjYMgk+HDzQBjhQ4fIB1
9Rr/ImViFMmu+FUkO+LrKMbAqQMsoCyO41mFaLFcTRHonlMGtAKnYgBO9H320yxAcI0pqocEVI+i
BqafXHxImbcAylVn9JwNeU4MPoRNAtT8sr/3QXAxYBozQsaWSK6Q/2qYK6lopTi4mCPyfpOrYr0j
zycFTpxxxKZ8q5LBmp4/TwplQ+LT1JZWUfsgxbqgkjC5Yo7LandnJwsEnTLfQEwX+I1ehdyi8yHB
3JqQcGKGsHbQhgUaSOiBbowh1sF6Ul4flhdUECH+473w6rdJSIOQO9wCOJcSwc+qId574r0v3gfi
/UK8X4r3K/F+Ld5v+NuoFjGEXNV7bNpCHvDmAWce8OUBVx7w5AFHHsbnYWwexuWNKv5nFEsIj8AG
QFcqlSL7P4uWv55LVhQXGjWzZuaomhjHGNnYlJtYZFhoUbO7SFC5L8HAXKQq6pPbkK85zQZQidFA
mTa/jXmB/oU1pq1AcwfMFTyTy3wWrV9RVrUXbSAXqfRa2BiUT8O57xLeI7Sd9KjwJxQUOGDrSWo9
ti3VbFSKT4m/iorYw1+PVEd3pCpPj96SGhvCm4fe/Nqh5KPpqOoD9q0KAzByYeDH2xThrD0tD0AC
oxRyf8Hhmmf6oAjFVT2Skq6BwEE6zD9x+mEmQdymHlOnb00aufdUKGVsEymdX3i2JLsDFQGGFvUh
0EJ2WJpYqeo9jy29YrwYwep1lPeq+0V5cs/fk4IVmplSMm1tD2jsnCVxQl01pVw7vdPj7Xr6lhZI
VbB+HQXhSeVnRNL09LrsN5T7cplvLO97zdkk5bduDi3E0Tl3EQqEyt+CX6AFABXMpxCiHYe4KqYS
oR+pSxYT+C+cUMhk7QAgyGjuWiyHldGaDlFVMouJDTIuFMRENdK55PhoUBDEFMnTGmldNZtJCXQu
Rz6lUzoVoyMWwErX2APAIjP1X6nVC81wHvTvZpTwHt7AaFEbCtHeIZth6L0bUstmMvogGHXerfcG
vUbrvFkf9K86zTr544+VcAygN2j/8BDQabvzfnDS7n//MNDFxXHrHaBCCoUGeDfCcFlexaUWiHUG
BORh4h7DpVw4cze0HcZrFBtHQYcshWqMMDKxspPaR+xQfIMvMJ2A8mTl0d0VMh83E53LgDNXtONy
lMrByfG7YjYDsBkQtu3awaQQ7b0yco1sXvgN65T6BFtrKgbC0jMZ9GWQEXREYQF8iwWMcEOmtIfk
vTcnwcSbO8MSmXgLUGEwUB9VC/MIyDGtCbVuBJ5IQYk5wrSTmpCWdi7HNORrJcChziUFzSrh0IBS
3DaZ7h0fr5kLscCRgtsjwznb74HJwHbSs2gQ4E9vxFosbzoFo60wBGA0mQIacnGpJUfsQZ4lVJ6p
dESnBoqykEDS2jKMf8BA0BNKHBM2cVho4iSsRQOAXUMguMGveznNU80shVFFs3UumdrExpZZLvuk
8Dn+9Oj72BZQKY4i5/DQxj7WzpmA6AF0pKPgjwymXdITaRUAufNHJpbIYNBstOqDwSqFZRHQs26Y
bPCDKoJhMRHoYABvSTW1m1trXgmtzy6iRSZiRpda1P4IJl2TIFlmPEznNT4UydQeT0Ju4ExDA+qA
C8Ft+pD9B5ABxILAIwtKXApIQ49hskTgwEG2O5uH6IPwx8j2sXIGBsWUqILQbER/ghh+VfoCsrAh
7khUEo1zx8MO1jSBROmVkByGKKKL4d4VK8fWu74nA1pNaAkXjPSTbP/POCb8y1OVYVIqiq+5tIOT
eXDHCQWLB+KBReAFwpBOZyHftgKv2BZq5HtTwUUfPM8Rx8GiJ6QmFLCJpTbYSqdzYNQ1rvujdwOc
ZZwroddBHNc4LfpUytFwCtCjESpdCOlSSEGoa9FDMgnDGVZkF4tFRdZdb52K5493wUkGu9bcB8hw
l9d5TVx3ZRJOncgXcc+hMfGPPyIOqH7diIyc25a6KhWuinAZPfvexMrSvoE7By4eXH8btEQoNMEC
cwnVFMtuKKqF5/s28NW89oDbyFPPHwL7vJEYjU2JpAeG/wfFsjBdJlxFzaf420RnKYaPQCLS16to
CM8MKxxsAx/LFidVr8tNkOutTMNkBOHJWMiUJI4mQqeXiawa+2U1lqwMJKq4REiJ44nayXAKgSDZ
LOfw6QwGgLZBaEVtxfgnZmU7Y4JB0RE7DSwthUJuEoudkCvBNQOIBanLxPwIjYDLnjky0wsqYqRE
8FPkrVCEoe3OqZAlSoynR4APlg7U9N63TgmkU4E5phLRLlO0jBys7964Fm6ac/IArUToZOLXaXTq
TP2RIGE7SETCqUvHpgfZpNTY1kbGbGE3S6N2cRMr9XGzt56R6rRprJM6rkhpYdpcOZj/ZOETm68p
d+ysizv+MbhI9KkLOxCuUQQK5iEFMfZ0Soc2OE8IJkJ3WDfzqo7nzaTVSLrEIQ6iGg3lKzqxkVCQ
QgUOpTNGjlGdBhrpWhyMUlSxGGUujEiYgKFbwp2iIjk+cYXNjQOPkj24K2OBrNNughR4zocRDvew
yIdnHLCE+0oxiZIZMl+Afh0+IQ8hz57hVgD2ddBeb7T63aKaLo49NA9JKqwwsMeu6VRYLLdgzwje
lLEV7ejahNzGAZb7FeH1UiE5SkdUw0J9yWQo9HBPw/OjpEaOxP45CMGFQ1KfOzPB2THVwQUDmXHQ
EyyviKUdkq+G/3Zhd81+cqXFmbRtjdyjpp0bfqQT17Q7WJrHAhPruLJoC21a4RwYd8czBqErsYos
YRo3dzEPvpJZ8GefXWGWzIsywDyWchDu6mVdJcn7JvrliK36KZiMGDhTvOFnKqVgl96R0XtmU2dY
4KR1zgfvGsfng95ls9c/7tcVVrMEWqJ4mgxGj6iLxIdkB4xsiUpzTkxqnBciIDBi2Xb5gjeks3oJ
uaK8kaJFECCGxQWfzAq+SU+KXWIrJKdercNaeWWJ8t4r5zRXSMchD8fJuynkl7ItCtlldJxly4Pw
+QGa56JgmGi2lEJEmR9/fsjKcuLUtF120mH6Yys6uIMfH7UTD6bhUSg14nI2J6QJE57ifNC58ig/
HsTJXDYodaivVijjZfT4Ia5mFLzi6fLDG/1gUavG8zKt0js1f+0l21j1URIn2ttg1bzIiulFEM0e
E6jULE/kFQNRnS2KQ6CHa8HwKy5FFlXUKu4Y6/po8ajKG0lipF/Q/ZK2It1FaV2JPCsIj6IDSAzZ
TGtbWH6JVZ7P60LjUaItuBVV6Hs+sGkH4S8fMNKv8CQ5BmbkSlpr+vguyZLYM92XHkS9l0Cd40qp
HM316n1xMFfLyzO5vVpeHsvt1/LyZO6glpenmy9qeDj54DldLS+P6F7V8vKU7nUt/0Ye2NXYeSY/
tINvg/z0fb1bFyqdN2Lk4mQiriuz3YvcrIB5syJdIJMgVHlvFh6pO/ECNABWyCTgo8DdA/oFWIN9
OD+0DnO8gFw2kv4tWNihNSGIYFk4sEyIv1/bXx/qm5qUIzFDz0YcMGkivos0Wkc4TyBMO5kNEVoJ
hEvcj7QnS5zw8msdYgo87C+phldMzCrOgZN4S2QdGrWzJ4w8SQa+raXLWht76/sIfZKdy9Bv7NcF
+ZH7YaULZMbwOsUWud0l35LEDbjDlGjUvCdVCH+qFcLbP3xe7Q9Sco/Uu91B86SpLWo3vm5BQhMP
3PiWSdypQG/Cc05hg8LN8gK3nHe5tzjt1tEh9Y9PmnXSOCOtdp/Uf270+j31/sAKV4POAhZIx1i2
7zYujrvvyQ/19w+7JkMeGs58atkBMPph+L0N4fc3hD/YEP7FhvAvN4R/tSH86w3h32wGb1RT8EV5
tSII08UQkcjGZfEQrSR5+rWWofBdw5qGgv8nkmlpO2esbD2kDg35aShTapvvz7g9PWQ4JNfvXrVO
YzOJDONvxoe6i95CL77JqM28G0UAed5yAd2J05Q1aP0k54b3FVzYUVxD5LtB/5wmLaAhQEiAaDqD
kfaZZy6PkDafxZcpIG3xTV6xiq5SIOSyezWPZNLFFfdsErdXPugXGMRm4DnhF1viFD9JeMenM6yW
I5l4DvoAoXsrKJGcd4cCWcTKOL1GCiuYjKcaA7xbVeVsl3VqiVnPlTeT1nKJxcovrzBGVzuwxlVg
VJTIsmseioXwpD8dUJdxLZEAreChuo3kvGS/xHWbyMOc1M8brVzEr2X/V5PlkhjzX8JbXUFlVrbk
Ypt2eegZ3xInaFc5wVVruES3qlKz4hlLeAlI/v0C7Fm1uXRu/dVsWVPS6Psb/b+JqNmhgnYIn6ql
PlKb+04UEj/dkMEsW94Cq/z8cBkLrr43H09Y8V/ca8OojtEcUhTPHwZLg/syI05sM/5/jJgxQ9av
2K7/rahesV+rr1gusX7tBqFmkYFm+XLR61m/8SWtP72OT+Prat5y/i7h9NYvkD/FLywvfSfKy3j+
JtAcRtlkqhywqrjvU5oC1m6VMwhFC0VnsvlE5hlRpxbkAvbHPQr52irwHOh//ZeN22ed58K8oSPb
oX/mHA///W/V2N+Tf/+7t/9qH9oNY88wtn//+1c89Z/rZ41mHdzO0tO2bPvkn71VnRUv2zmHjWHr
rHEOMLvzwN+djcEzlI1Xu9e2Cz8G4IpG9jibPT3FEn0hmFDIevKFaFyRlMuWVcxmZan09Kx5fI5T
lsHv1qw3b0j53eC8dTXota+6p3VSHidBnwNsYxVu8ffEQ9svfuK4Mr89ByQ2Gyc9gpQ1V42a3Ywd
+5pNxoCfPwSchFwFNhw55jhQMP7klMonwzvINGyLlJ3Z7aMo7GsYn/VgGb49pEQw4BAH6EwpQov4
ymYhQT2E30JFigT8/VcVdn+hYmUzAHiqgJMy0OKR/Hck/zabjUchBlSiYnqE6IB3813UhEspckzZ
LJaE3MNsxp+S8kiBl8iz2Urn+3br/SFLphn0Nu5sn+2zfbbP9tk+22f7bJ/ts322z/bZPqnnv41C
h6cAUAAA
--Apple-Mail-9E672DF7-4C59-404C-80BA-CE751EA3EDF0
Content-Type: text/html;
charset=us-ascii
Content-Transfer-Encoding: 7bit
<html><head><meta http-equiv="content-type" content="text/html; charset=us-ascii"></head><body dir="auto"><div dir="ltr"></div></body></html>
--Apple-Mail-9E672DF7-4C59-404C-80BA-CE751EA3EDF0--
--Apple-Mail-DDE01288-E681-4DEB-9F9F-3E33446FF276--
Attachments:
[application/octet-stream] query-data-send-error.tgz (4.3K, ../../DCCA2B1C-0301-46B5-B1A4-DFAD8581CB5D@gmail.com/2-query-data-send-error.tgz)
download
^ permalink raw reply [nested|flat] 8+ messages in thread
end of thread, other threads:[~2025-06-10 00:40 UTC | newest]
Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2025-04-29 16:35 BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq PG Bug reporting form <noreply@postgresql.org>
2025-04-29 18:06 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-04-29 18:48 ` Jacob Champion <jacob.champion@enterprisedb.com>
2025-06-07 05:01 ` BATBAATAR Dorjpalam <htgn.dbat.95@gmail.com>
2025-06-09 14:26 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-06-09 17:02 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-06-10 00:40 ` Tom Lane <tgl@sss.pgh.pa.us>
2025-06-07 07:20 Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq BATBAATAR Dorjpalam <htgn.dbat.95@gmail.com>
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