Re: Intermittent errors when fetching cursor rows on PostgreSQL 16

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:
>
>