public inbox for [email protected]  

help / color / mirror / Atom feed

From: Enrico Schenone <[email protected]>
To: Adrian Klaver <[email protected]>
To: [email protected]
Cc: Massimo Catti <[email protected]>
Cc: Livio Pizzolo <[email protected]>
Subject: Re: Intermittent errors when fetching cursor rows on PostgreSQL 16
Date: Tue, 24 Dec 2024 23:23:04 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

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

view thread (15+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: Intermittent errors when fetching cursor rows on PostgreSQL 16
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox