Content-Type: multipart/alternative;
 boundary="------------U6e0jfNrlHMp8vCXohLTRIax"
Message-ID: <ec5ce003-6ad9-4cfd-8186-6ca66f285ad3@cleistech.it>
Date: Tue, 24 Dec 2024 23:23:04 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Intermittent errors when fetching cursor rows on PostgreSQL 16
To: Adrian Klaver <adrian.klaver@aklaver.com>,
 pgsql-general@lists.postgresql.org
Cc: Massimo Catti <mcatti@cleistech.it>, Livio Pizzolo <lpizzolo@cleistech.it>
References: <446423eb-4a4e-4135-bbb8-4d0e5c7aac3b@cleistech.it>
 <25d5fb16-9bb2-4ad1-969c-eaca03ccbaaf@aklaver.com>
 <6ce80aaa-970b-4432-938a-39a07f811599@cleistech.it>
 <9f60eb26-7d34-4228-bd78-74c6deb90e54@aklaver.com>
 <282c2a48-bb12-4486-b03d-563523cac81b@cleistech.it>
 <2645a89e-d661-4f2b-92b3-01154a78d535@aklaver.com>
 <e2332684-8d0f-47ba-a5ef-5b2b9c9f8cf0@cleistech.it>
 <54689a6a-839c-44c4-90b5-b9692e8e7cb0@aklaver.com>
 <4efe42a2-789c-4957-a564-25199869f6ec@cleistech.it>
 <e906a6a1-e97d-4bf7-afe3-21a430b3a944@aklaver.com>
Content-Language: it
From: Enrico Schenone <eschenone@cleistech.it>
In-Reply-To: <e906a6a1-e97d-4bf7-afe3-21a430b3a944@aklaver.com>
Archived-At: <https://www.postgresql.org/message-id/ec5ce003-6ad9-4cfd-8186-6ca66f285ad3%40cleistech.it>
Precedence: bulk

This is a multi-part message in MIME format.
--------------U6e0jfNrlHMp8vCXohLTRIax
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi, Adrian.
I'm arranging a test program with two nested cursors in two versions:

 1. 4Js Genero BDL language
 2. pure C with libpq language

I'll put both programs in stress execution into the production 
environment looking for some hours how they behaves.
Possible combinations are:

 1. no-one throws an error
 2. only the 4Js Genero version throws an error
 3. only the pure C version throws an error
 4. both versions throws the error

This stress test should address further investigations.
I'll keep you informed.

Regards.
Enrico Schenone

Il 20/12/24 17:43, Adrian Klaver ha scritto:
> On 12/20/24 07:02, Enrico Schenone wrote:
>> Hi, Adrian.
>> Today I have collected a tcpdump at client side with communications 
>> between application server and db server while the issue was 
>> occurring one time per second on another program.
>> I send you two files.
>> The first one is a zipped tarball (.tgz) containing a text 
>> representation of the tcpdump starting at point where it reports the 
>> declaration of the failing cursor ("cu4" as you can see in the first 
>> line of the file) and subsequent fetch. Consider that the client 
>> application log detected the XX001 error on the first FETCH of the 
>> cursor at 2024-12-20 12:17:35.175
>> The second file (zipped tarball .tgz) is too big to be sent as 
>> attachment, so I provide a link where it can be downloaded. It is the 
>> fraction of tcpdump recorded during the program failure (occurred 
>> several times). It is in .pcap format so it is possible to open it 
>> with Wireshark or tcpdump -A -r
>> Anyone interested can download it at 
>> https://cleislabs.cleistech.it/downloads/tcpdump_out009.pcap.tgz
>>
>> Consider that during the dump several different cursor was declared 
>> with the name "cu4", but the one failing is the one of the first line.
>> Maybe an expert (I'm not so expert) can see if the disconnection is 
>> really made by the client and/or if the data returned by the server 
>> are really corrupted as per XX001 SQLSTATE.
>
> This is beyond me, someone else will need to chime in.
>
>>
>> Best regards.
>> Enrico
>>
>> Il 19/12/24 22:47, Adrian Klaver ha scritto:
>
>

--------------U6e0jfNrlHMp8vCXohLTRIax
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    Hi, Adrian.<br>
    I'm arranging a test program with two nested cursors in two
    versions:<br>
    <ol>
      <li>4Js Genero BDL language </li>
      <li>pure C with libpq language<br>
      </li>
    </ol>
    I'll put both programs in stress execution into the production
    environment looking for some hours how they behaves.<br>
    Possible combinations are:<br>
    <ol>
      <li>no-one throws an error</li>
      <li>only the 4Js Genero version throws an error</li>
      <li>only the pure C version throws an error</li>
      <li>both versions throws the error</li>
    </ol>
    This stress test should address further investigations.<br>
    I'll keep you informed.<br>
    <br>
    Regards.<br>
    Enrico Schenone<br>
    <br>
    Il 20/12/24 17:43, Adrian Klaver ha scritto:<br>
    <blockquote type="cite"
      cite="mid:e906a6a1-e97d-4bf7-afe3-21a430b3a944@aklaver.com">On
      12/20/24 07:02, Enrico Schenone wrote:
      <br>
      <blockquote type="cite">Hi, Adrian.
        <br>
        Today I have collected a tcpdump at client side with
        communications between application server and db server while
        the issue was occurring one time per second on another program.
        <br>
        I send you two files.
        <br>
        The first one is a zipped tarball (.tgz) containing a text
        representation of the tcpdump starting at point where it reports
        the declaration of the failing cursor ("cu4" as you can see in
        the first line of the file) and subsequent fetch. Consider that
        the client application log detected the XX001 error on the first
        FETCH of the cursor at 2024-12-20 12:17:35.175
        <br>
        The second file (zipped tarball .tgz) is too big to be sent as
        attachment, so I provide a link where it can be downloaded. It
        is the fraction of tcpdump recorded during the program failure
        (occurred several times). It is in .pcap format so it is
        possible to open it with Wireshark or tcpdump -A -r
        <br>
        Anyone interested can download it at
        <a class="moz-txt-link-freetext" href="https://cleislabs.cleistech.it/downloads/tcpdump_out009.pcap.tgz">https://cleislabs.cleistech.it/downloads/tcpdump_out009.pcap.tgz</a>
        <br>
        <br>
        Consider that during the dump several different cursor was
        declared with the name "cu4", but the one failing is the one of
        the first line.
        <br>
        Maybe an expert (I'm not so expert) can see if the disconnection
        is really made by the client and/or if the data returned by the
        server are really corrupted as per XX001 SQLSTATE.
        <br>
      </blockquote>
      <br>
      This is beyond me, someone else will need to chime in.
      <br>
      <br>
      <blockquote type="cite">
        <br>
        Best regards.
        <br>
        Enrico
        <br>
        <br>
        Il 19/12/24 22:47, Adrian Klaver ha scritto:
        <br>
      </blockquote>
      <br>
      <br>
    </blockquote>
    <br>
  </body>
</html>

--------------U6e0jfNrlHMp8vCXohLTRIax--