Re: Intermittent errors when fetching cursor rows on PostgreSQL 16

Good day, Adrian.
First of all I thank-you for you answer.

Yes, the client is running on Ubuntu 22.04 LTS in this case, bu I have
observed the same problem on Debian 10 and 12 and Postgres versions 12,
13 and 16.
In the reported case no relevant  info has been reported on  syslog
and/or kern.log at both client and server sides.
What is different between production and test environment in the
reported case is
the OS (Debian 12  on test DB server and Debian 10 on ckìlient server)
the test DB is a clone of the production DB but no other task was
running at client side, while in production we have a lot of SQL
operations running invoked by a lot of batch (daemons) services running
on production client.

This is a typical load of the DB server ...

top - 08:18:38 up 28 days, 13:53,  1 user,  load average: 1,15, 1,39, 1,29
Tasks: 381 total,   2 running, 379 sleeping,   0 stopped,   0 zombie
%Cpu(s):  3,5 us,  1,7 sy,  0,0 ni, 94,1 id,  0,0 wa,  0,0 hi, 0,7 si, 
0,0 st
MiB Mem :  64394,2 total,  35903,3 free,   1001,4 used,  27489,6 buff/cache
MiB Swap:  65536,0 total,  65519,1 free,     16,9 used.  58034,8 avail Mem

At the time the error occurs, dozens of other SQL sessions are active &
running on DB server, and no-one is reporting any error at-all (not only
fetch errors).
This happens sometimes also in system with no (or low) stress situations.

One of things I don't understand is why at client side I get the XX001
error on the FETCH (normally the first fetch) while at server side I
heve no error related to the fetch forward ?
Another is why in the meantime no other client application report an
error, considering that there may be several parallel instances of the
same client application ?
And finally why after seconds or minutes the same process newly
instantiated works with no more errors ?

I can suppose that the client closes the connection once got the XX001
error, but I can't say why it receives this error while it is not
reported at server side and not block i/o error is reported.
Is it a false positive or what ?

Four Js support said <We use the standard C API provided by the DB
vendor. In the case of PostgreSQL, we use the C API client -
https://www.postgresql.org/docs/current/libpq.html >

At client side I have installed the following PostgreSQL packages ...

    postgresql-client-16:amd64/jammy-pgdg 16.5-1.pgdg22.04+1
upgradeable to 16.6-1.pgdg22.04+1
    postgresql-client-common:all/jammy-pgdg 262.pgdg22.04+1 upgradeable
to 267.pgdg22.04+1

Best regards.
Enrico

*Enrico Schenone*
Software Architect

*Cleis Tech s.r.l.* - www.gruppocleis.it
Sede di Genova, Via Paolo Emilio Bensa, 2 - 16124 Genova, ITALY
Tel: +39-0104071400   Fax: +39-0104073276
Mobile: +39-320 7709352
E-mail: eschenone(at)cleistech(dot)it

<https://gruppocleis.it><https://ibm.biz/BdqAJh>

<https://ibm.biz/BdqAJh>
<https://ibm.biz/BdqAJh>
Il 19/12/24 00:11, Adrian Klaver ha scritto:
> On 12/17/24 08:30, Enrico Schenone wrote:
>> Good day.
>> My name is Enrico Schenone, from Genoa, Italy.
>> I'm a software achitect working at Cleis Tech - Genoa - Italy  -
>> http://gruppocleis.it
>> Me and my team are using PostgreSQL v12 to v16 on Debian 10-12 and
>> Ubuntu Server 22.04 LTS with no-cluster configuration.
>> Our applications are developed with 4Js Genero platform (classified
>> as LCAP) - https://4js.com
>>
>> I whish to report an issue where I can't say if it happens at server
>> or client side (or both as well).
>
> This:
>
> "unexpected EOF on client connection "
>
> makes me believe this is on client side.
>
> To be clear the client is running on Ubuntu Server 22.04, correct?
>
> Have you looked at the OS system log for relevant entries at the time
> the error occurs?
>
> If so what are they?
>
> This only happens in production environment, is there anything in it
> that is materially different from where you ran the test below?
>
>
>> Hoping you can help me or address to someone who can do it.
>> Thanks in advance.
>> Enrico
>> --
>>
>> *Enrico Schenone*
>> Software Architect
>>
>