Search Postgresql Archives

Re: Intermittent errors when fetching cursor rows on PostgreSQL 16

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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:




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]

  Powered by Linux