Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq - Mailing list pgsql-bugs

From BATBAATAR Dorjpalam
Subject Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq
Date
Msg-id 1ba0f64a-9f35-4fb4-83b0-6c11a1b88740@gmail.com
Whole thread Raw
In response to Re: BUG #18907: SSL error: bad length failure during transfer data in pipeline mode with libpq  (Jacob Champion <jacob.champion@enterprisedb.com>)
List pgsql-bugs
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

Attachment

pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #18948: Equivalent MAX() result in view and inline query yields inconsistent row count
Next
From: Amit Kapila
Date:
Subject: Re: Logical replication 'invalid memory alloc request size 1585837200' after upgrading to 17.5