Content-Type: multipart/alternative;
 boundary="------------wuQE9zIoj0HIaLfqGkGbJIhe"
Message-ID: <6ce80aaa-970b-4432-938a-39a07f811599@cleistech.it>
Date: Thu, 19 Dec 2024 08:52:34 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Enrico Schenone <eschenone@cleistech.it>
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>
Content-Language: it
In-Reply-To: <25d5fb16-9bb2-4ad1-969c-eaca03ccbaaf@aklaver.com>
Archived-At: <https://www.postgresql.org/message-id/6ce80aaa-970b-4432-938a-39a07f811599%40cleistech.it>
Precedence: bulk

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

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=20
observed the same problem on Debian 10 and 12 and Postgres versions 12,=20
13 and 16.
In the reported case no relevant=C2=A0 info has been reported on=C2=A0 sy=
slog=20
and/or kern.log at both client and server sides.
What is different between production and test environment in the=20
reported case is
the OS (Debian 12=C2=A0 on test DB server and Debian 10 on ck=C3=AClient =
server)
the test DB is a clone of the production DB but no other task was=20
running at client side, while in production we have a lot of SQL=20
operations running invoked by a lot of batch (daemons) services running=20
on production client.

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

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

At the time the error occurs, dozens of other SQL sessions are active &=20
running on DB server, and no-one is reporting any error at-all (not only=20
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=20
error on the FETCH (normally the first fetch) while at server side I=20
heve no error related to the fetch forward ?
Another is why in the meantime no other client application report an=20
error, considering that there may be several parallel instances of the=20
same client application ?
And finally why after seconds or minutes the same process newly=20
instantiated works with no more errors ?

I can suppose that the client closes the connection once got the XX001=20
error, but I can't say why it receives this error while it is not=20
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=20
vendor. In the case of PostgreSQL, we use the C API client -=20
https://www.postgresql.org/docs/current/libpq.html >

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

 =C2=A0=C2=A0=C2=A0 postgresql-client-16:amd64/jammy-pgdg 16.5-1.pgdg22.0=
4+1=20
upgradeable to 16.6-1.pgdg22.04+1
 =C2=A0=C2=A0=C2=A0 postgresql-client-common:all/jammy-pgdg 262.pgdg22.04=
+1 upgradeable=20
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 =C2=A0 Fax: +39-0104073276
Mobile: +39-320 7709352
E-mail: eschenone@cleistech.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=C2=A0 -=20
>> http://gruppocleis.it
>> Me and my team are using PostgreSQL v12 to v16 on Debian 10-12 and=20
>> Ubuntu Server 22.04 LTS with no-cluster configuration.
>> Our applications are developed with 4Js Genero platform (classified=20
>> as LCAP) - https://4js.com
>>
>> I whish to report an issue where I can't say if it happens at server=20
>> 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=20
> the error occurs?
>
> If so what are they?
>
> This only happens in production environment, is there anything in it=20
> 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
>> --=20
>>
>> *Enrico Schenone*
>> Software Architect
>>
>

--------------wuQE9zIoj0HIaLfqGkGbJIhe
Content-Type: multipart/related;
 boundary="------------7PgLauRTfrFMSuSkkIZrH0nz"

--------------7PgLauRTfrFMSuSkkIZrH0nz
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF=
-8">
  </head>
  <body>
    Good day, Adrian.<br>
    First of all I thank-you for you answer.<br>
    <br>
    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.<br>
    In the reported case no relevant=C2=A0 info has been reported on=C2=A0=
 syslog
    and/or kern.log at both client and server sides.<br>
    What is different between production and test environment in the
    reported case is<br>
    the OS (Debian 12=C2=A0 on test DB server and Debian 10 on ck=C3=ACli=
ent
    server)<br>
    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.<br>
    <br>
    This is a typical load of the DB server ...<br>
    <br>
    <font size=3D"4" face=3D"monospace">top - 08:18:38 up 28 days, 13:53,=
=C2=A0 1
      user,=C2=A0 load average: 1,15, 1,39, 1,29<br>
      Tasks: 381 total,=C2=A0=C2=A0 2 running, 379 sleeping,=C2=A0=C2=A0 =
0 stopped,=C2=A0=C2=A0 0
      zombie<br>
      %Cpu(s):=C2=A0 3,5 us,=C2=A0 1,7 sy,=C2=A0 0,0 ni, 94,1 id,=C2=A0 0=
,0 wa,=C2=A0 0,0 hi,=C2=A0
      0,7 si,=C2=A0 0,0 st<br>
      MiB Mem :=C2=A0 64394,2 total,=C2=A0 35903,3 free,=C2=A0=C2=A0 1001=
,4 used,=C2=A0 27489,6
      buff/cache<br>
      MiB Swap:=C2=A0 65536,0 total,=C2=A0 65519,1 free,=C2=A0=C2=A0=C2=A0=
=C2=A0 16,9 used.=C2=A0 58034,8
      avail Mem </font><br>
    <br>
    At the time the error occurs, dozens of other SQL sessions are
    active &amp; running on DB server, and no-one is reporting any error
    at-all (not only fetch errors).<br>
    This happens sometimes also in system with no (or low) stress
    situations.<br>
    <br>
    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 ?<br>
    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 ?<br>
    And finally why after seconds or minutes the same process newly
    instantiated works with no more errors ?<br>
    <br>
    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.<br>
    Is it a false positive or what ?<br>
    <br>
    Four Js support said &lt;<span id=3D"root">We use the standard C API
      provided by the DB vendor. In the case of PostgreSQL, we use the C
      API client - <a class=3D"moz-txt-link-freetext" href=3D"https://www=
.postgresql.org/docs/current/libpq.html">https://www.postgresql.org/docs/=
current/libpq.html</a>
      &gt;<span data-inline-card=3D"true"
data-card-url=3D"https://www.postgresql.org/docs/current/libpq.html"><spa=
n
          class=3D"loader-wrapper"><span><span aria-expanded=3D"false"
              aria-haspopup=3D"true"
              data-testid=3D"hover-card-trigger-wrapper"></span></span></=
span></span></span><span
      id=3D"root"> </span><br>
    <br>
    At client side I have installed the following PostgreSQL packages
    ...<br>
    <br>
    =C2=A0=C2=A0=C2=A0 postgresql-client-16:amd64/jammy-pgdg 16.5-1.pgdg2=
2.04+1
    upgradeable to 16.6-1.pgdg22.04+1<br>
    =C2=A0=C2=A0=C2=A0 postgresql-client-common:all/jammy-pgdg 262.pgdg22=
.04+1
    upgradeable to 267.pgdg22.04+1<br>
    <br>
    Best regards.<br>
    Enrico<br>
    <br>
    <div class=3D"moz-signature">
      <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DU=
TF-8">
      <br>
      <div <p=3D""><font size=3D"4" face=3D"Arial"><b>Enrico Schenone</b>=
 <br>
        </font> <font size=3D"3" face=3D"Arial">Software Architect<br>
        </font>
        <p></p>
        <p> <font size=3D"4" face=3D"Arial"><b>Cleis Tech s.r.l.</b></fon=
t>
          <font size=3D"2" face=3D"Arial"> - <a
              class=3D"moz-txt-link-abbreviated"
              href=3D"http://www.gruppocleis.it" moz-do-not-send=3D"true"=
>www.gruppocleis.it</a>
            <br>
          </font> <font size=3D"2" face=3D"Arial">Sede di Genova, Via Pao=
lo
            Emilio Bensa, 2 - 16124 Genova, ITALY<br>
            Tel: +39-0104071400 =C2=A0 Fax: +39-0104073276<br>
            Mobile: +39-320 7709352<br>
            E-mail: <a
              class=3D"moz-txt-link-abbreviated moz-txt-link-freetext"
              href=3D"mailto:eschenone@cleistech.it"
              moz-do-not-send=3D"true">eschenone@cleistech.it</a> <br>
          </font> </p>
        <p> <a href=3D"https://gruppocleis.it"> <img
              src=3D"cid:part1.cFBLuS0r.gxdfm80i@cleistech.it"
              name=3D"LogoCleis" style=3D"margin-left: 0cm" width=3D"268"
              height=3D"64" border=3D"0"> </a><a
            href=3D"https://ibm.biz/BdqAJh"><img
              src=3D"cid:part2.eRjrvMqn.5DxA7ehy@cleistech.it"
              name=3D"HTTPS://IBM.BIZ/BDQAJH" style=3D"margin-left: 1.5cm=
"
              width=3D"48" height=3D"48" border=3D"2"> </a></p>
        <a href=3D"https://ibm.biz/BdqAJh"> </a></div>
      <a href=3D"https://ibm.biz/BdqAJh"> </a></div>
    <div class=3D"moz-cite-prefix">Il 19/12/24 00:11, Adrian Klaver ha
      scritto:<br>
    </div>
    <blockquote type=3D"cite"
      cite=3D"mid:25d5fb16-9bb2-4ad1-969c-eaca03ccbaaf@aklaver.com">On
      12/17/24 08:30, Enrico Schenone wrote:
      <br>
      <blockquote type=3D"cite">Good day.
        <br>
        My name is Enrico Schenone, from Genoa, Italy.
        <br>
        I'm a software achitect working at Cleis Tech - Genoa - Italy=C2=A0=
 -
        <a class=3D"moz-txt-link-freetext" href=3D"http://gruppocleis.it"=
>http://gruppocleis.it</a>
        <br>
        Me and my team are using PostgreSQL v12 to v16 on Debian 10-12
        and Ubuntu Server 22.04 LTS with no-cluster configuration.
        <br>
        Our applications are developed with 4Js Genero platform
        (classified as LCAP) - <a class=3D"moz-txt-link-freetext" href=3D=
"https://4js.com">https://4js.com</a>
        <br>
        <br>
        I whish to report an issue where I can't say if it happens at
        server or client side (or both as well).
        <br>
      </blockquote>
      <br>
      This:
      <br>
      <br>
      "unexpected EOF on client connection "
      <br>
      <br>
      makes me believe this is on client side.
      <br>
      <br>
      To be clear the client is running on Ubuntu Server 22.04, correct?
      <br>
      <br>
      Have you looked at the OS system log for relevant entries at the
      time the error occurs?
      <br>
      <br>
      If so what are they?
      <br>
      <br>
      This only happens in production environment, is there anything in
      it that is materially different from where you ran the test below?
      <br>
      <br>
      <br>
      <blockquote type=3D"cite">Hoping you can help me or address to
        someone who can do it.
        <br>
        Thanks in advance.
        <br>
        Enrico
        <br>
        --=C2=A0<br>
        <br>
        *Enrico Schenone*
        <br>
        Software Architect
        <br>
        <br>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>
--------------7PgLauRTfrFMSuSkkIZrH0nz
Content-Type: image/jpeg; name="LogoCleis"
Content-Disposition: inline; filename="LogoCleis"
Content-Id: <part1.cFBLuS0r.gxdfm80i@cleistech.it>
Content-Transfer-Encoding: base64

/9j/7gAhQWRvYmUAZIAAAAABAwAQAwIDBgAAAAAAAAAAAAAAAP/bAIQADAgICAkIDAkJDBEL
CgsRFQ8MDA8VGBMTFRMTGBEMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAEN
CwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwMDAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwM
DAwMDAwMDAwM/8IAEQgANwDlAwEiAAIRAQMRAf/EANIAAAEFAQEBAAAAAAAAAAAAAAADBAUG
CAIBBwEAAwEBAAAAAAAAAAAAAAAAAAECAwQQAAEEAgEEAQQDAQAAAAAAAAQBAgMFAAYREBIT
FRQwISIHIDEjFhEAAgECAwUCCAkICwAAAAAAAQIDERIAEwQhMSIyBUIjEEFRUmKCMxSBcpKi
0kNTc5MwYaHRY4M0FUBxkbHBwrNEhDUGEgABAwIBCQUFCAMAAAAAAAABABECIRIxEEFRgSIy
QmIDYZFSgtIwcaFyoiCxwbLCE9MUQ3Oj/9oADAMBAQIRAxEAAAD6qHACSVeNLcRfNZyxDvQd
kQxaspG8IlSFfA8KzKMkhNSGeJ1PG7gV1lFW8qUiyc9p1jaelRlUTQHRnw2UYTrQr7Q7zuc1
21fPybxIoLTnT5eu2jaXtfs1Dl2ZGbayQNhoX0exz6HPRXLDWefWxV+TiIZLR6sU1TUcQ463
1+V2h8B14iC4Onup+ONCJsSl512a56c1lxJpmj6v2Tsz4hZsCGnknKOwIfETKR+N9IrGdJPW
SoJybApdcyHekoC5SDKpS1UZVA1UZVA1UZVA1F3loZqoyqI1UZVA1UZVA1UZVA1QwzMRWnOs
wkmoOMxDNOe5iEap9yqazqoyqB//2gAIAQIAAQUAxqPc7t+6pwqMVU7fureFVip0mlczFIei
NIcuRTq9WTuc/F5V034rAqrMruVcqJHB+UqPXvm+3QpzUZPJGsUTmpKqIuD9jJMVOU738Md4
0V6uzyzdzZFbjXqmOerukvj5/wAVxjoURr4Wp4mKvYn8fv8Axf4+U8PP+Xd/j1//2gAIAQMA
AQUAROcVsbY+nPXnoxiOxI28rGmPjREdGiJjexGI5HI9GePjE/t32Tj7N6QovdG1yPciqzJO
VbjXK1VVjkkc6R3GKyHs45zjETjozu45fio/lUeud7uOV+kndn55+XH59f/aAAgBAQABBQDp
LLHDGEcGfD9fubnKZ3NzlFxVRM7m9OUxFRessscMb5ay1rQCtLAgr49esoLL/nauGsk1q1b6
msyyXW6qL3mk+IEehsBbFuvVkFZNrFtj6ypjYy90p+BjUZw0A8A7MJYrx1qvEgNXKyF1X41d
UyxI/wCXYVjq1rVriFSulE80lCBILLksscMb/X3VfbBiz34tXrhtdUaxU09fvxVMmu67QAjU
fqazP2YwIKorB6EQMLX6kMX9hxgAa7qdCFBru7VMKazpUdHc61Xa/XCANa1jemxNGUwTj4t4
0VbEiykKhoBhoxD4hpLRssQ8Mw4sTYePDh4UJ4YWvVFYHrIQFhuQmv0tQGyuorITYKQSPZiQ
qYSP1FbmzhjHbvPr2uVxHqK3N+GgnvG09Y1scNNNZWdQzXN2jrAYpOkkjIo7K3CMlDvKyQc+
1EJJLtKOQeqsxxxXWA89jZRyNs7uaOEyutQDk6HBwnCFfryvY2u1oIyCu1ivrxnfr9rrMfUR
EsVrq17JNMHguB9RgKOcDUov/FBk26VIPE+ktdaC6UP7McMcZekrHPiSmtUSCssI2emtcSms
+SQ5ZBI6izbI+JXSnVxxJA9WayP47vh9DRIjRKvWK+uH9SDkII47nUY7kJr5FAbJFcKGqnWU
tY2aUcJYZPUg56kHPUg5DFHDH0Kn+OMw6YZq2UySjnFyPEPN8ft5JYm20yN9ynELpHx/Sd8D
zD/H8X0H9nY0SnY1BqtuQD10SSwgvHghrGNQerSJw1d2J/XT/9oACAECAgY/AELQ8GqRWuZN
V9DJi494TgSPlTVfQyYuD7lUSHvGQNG5/m/TCaB/bx/2fxogwILPHfr/AM0RKNrB+L9UIIRs
Yadv+PIxAsaq6fShTpCGbxSUSC/TAl1JH6kS5qVCJMnIM6du4gTI02j5Ve5LG8jWroyNvU2w
MjEhycCYx/NKKiBKJw4o+pAmcZ0O3dGVv1XKU4sdoxoYcfnU4OAcGeLybsuyMUOn/iEbeYcq
aBIDMzIbR0aEQSwFHYbqLSNQypI1pg6qSfgMgE3oMRK236kI7VHGM9F+0jvC4YEzlK3l3kwJ
8W1ed35ldWvNLi5Vqt8vshfb2XINY+bDR6Vw3N2PauDDlwy//9oACAEDAgY/AGCkJmUesJAC
BGzbxXc2XN9kuW7vxlFEXfl9aDScZ931JwX7vVJPdXy+rJcJSHXExZEDZt8V3iuU+rOUv7N4
ane8vFFTvMh1wYxjBtm3d2vlyE6sjalhhTI4BRoRqKYAxrusaoAvg/Fw+VAsfjkEgWILg9ql
1ZTl/YvEhTZl4p3eJGczdKRclYIEHbbDmf0rBYZaN3Onp3RWah0ALAarU1Kdg+9a39lR9Szr
Oyz5f//aAAgBAQEGPwDwNLKwSNAWdjsAA3k4z9HKs0VSty+UeI1/oG8Y343jG/G3G8eDfjYf
C0srBI0BZ3Y0AA8ZOJe+SXRSqySSK1AB2qv2LcOkJbVQIxMusaGSaNTu49UkWQq4Oo0MUE8I
YpeqClV5vFgT6+GKGEmmZlFlB9Jo0ez18M/T4op0TYXELBa+bmPGqM2P4WL5A/VhZuoRRQRM
aCQxFlr5GaNHVPWxnViyvtPd5Lfl5NuE1mjhhl08tbJBHQGhKHnVW5lx7xroI4odxkyiyj47
Ro9nr4Y9Pji1CpzOsLBQfNzHjVLvQwzvpoVRQWZmVQABvZjhmAjEKtZ7yYHEN3m+8mPJ+fhN
VpYIZIJK2SBBRgCUuWo5eHFkEaxITW1QAK+XZ4JEC5hZSAhNtajlu7OAsvS4ImoOFtYQafCc
asfy1IxNCFULqC4k21sur3fx8WSdMgjYAcLawg/34zG6XFEPE51ZX51cSaeXSRTPGyBIV1Fb
lHbeZeJWXBV+m6dWGwqdYQR+nAMixxNCtpRZQ6gL7Os3xfOw80ug0xkkYs5998Z+HEztol0g
dRR1mMt3wHl8DSysEjQXO7GgAHjJxJGkgn0uoUozRn/HssuIf/L6Fymjge7XaliLmIXN1DO/
CuVp4FtRPtcZWihhfSFTEGiA2bLW4h9ZjJkRJbCzyTSgbt/j5URMRnpohY6qcJmRAbBGM2Qb
P3eNFDNp42mEKtKWUVvcZj3es2P4WL5Ixp4NPAkcupm5lUA2xi9h8to8dN6O0cGq1ksYSSIW
udiZmoml5uC7zsR6ZNPG6xC0Mygk/wBeGEMEccupkSJWCgEAHNkp6seNCs+njaaSMSyMygms
ne7fiq1uNa2i0yLKiqzFFF1gZWmpT9ndj3BoIjqYEaLUqVF3Fdlz+v5/2mNPpX08UjwxIjuV
BuZQA77fObARRaqgBQNwA8K5p6aGyv8AekiSlW3W/VYitspYtMvk3fV+hh8w9MutX+LLCX1r
ez5mMjU6rpEsVQctnYio5fFgzwrpbpjxPo65ZC7FFx5rcSof5U0jyBbZi2cSfFIo+sxqNHmd
IjWRrZYr3UVU0cSpTCZg6MmYgkW8uKqeV185GxHS2lopby7ux6Pgl0c9cqZbWtND5ajBRhei
1eSaY7fzlqWIqrjqWmno8Mq6nJKnxF1seJvujw4YSm5A1zzTsBtNFXdYmHyFSWGQMhkiatDu
ajV5lx03/wA/pGaRWZGnZzUkyNxctq8GniwJJoVVWZY0ArVnc2RxoteJmbHsF/T+vHTejQRg
Qx2GdBtBuJnlr/x48DqZ00OmjijaJlRbbmkaPL4U55OHLT73HsF/T+vHSui6SMI0pBktrvlc
RLX4qRyYCrp1AUUA27h8ONT0z3dDJp4o5HBqaiUyLbb6OV8/GiTSLdo9c6FYNuxJHyZYPio3
HFhZI4VV1NVIrsPhaSQ0RAWY+QDCy6XX6eNLKUm0zStXfdcyjh9HDW6gP7tGGmZUZQBy3Klu
DNp+oaaOMhQFl0rSNs394VxZo54IJ6jvH07OtBz8Fi82NRqNRrYZdMjqtYYGiCs3nKBx3YEk
Ov02XJKtkbaVjJv5M4jn9PAgTU6aE6ogwwvpsxz9p33L8vAiGs02mpGtIpdMZTTy3r2PQwYt
NMJXiUZlFZR5Ki9V8MukmrlzKVa00O3yYTU6TXTaLVwVZtVsII/aJ3dtq+l95hptX1Buqq6l
EZCEiQ7jIkUbOuev2kmGgQvI7EsZHJ3kUXgjMa8OD1T+YyjU3XDgUqNllqq13BZ6WItfruqS
a1YaskDlVjDEGNXVYzwW4fKpUErdezBW9IZnzMPr36lPHqSry5piUxhQKSIpa72cZxFq9X1L
UapdNIre5yAIl1uZH3a8vC2ZhkqodaAgyNUFuW5czCdTHVDJqQb0jCqUond2ql+ZYv3mBWMk
+M3OP8+JeqabXS6eeQgCMLfFYAq5UiM2ZLy3+1wOp9U1B106CkMYUxRR/nRL5ZLv3uGMKlS2
/iY7vjlvC6I1jMCA9K0J7VDgD+asaePJjxMsnUGkMqWxsY0Fhrz8PPj/ALVvwY8cXVHK+OkU
YP8AbTHu+nnMEmzvrVYmm+5W4eLCO3U2ZVYErlIKgdmuI5LqBK1Wg21+jjNg1zaZLQMsRo20
dq58TpPrmmzltUhFQofOWzHu2Y11lmb2t1LvDNpJqiOdSjFdhofJgwgvMWYszszLUnZyxFF8
WORvxJPp4LQgq5FKlmb5rs2FDO9VQICppuAR5PvZEFl2Joo2DTM2YrABalbbF3+YmXh1dxp5
EieKRKsHpItjCSNgiWpJ3n0MZkLXxI6yzSpWy5EEUUaFrbvtMNLJIWYnh2DYtVbL3cty/wCp
5+A7SZlFIFVUcTG6STh7UvbxyN+JJ9PHI34kn08cjfiSfTwI4wQi7gSTv28zVbwyz0uy1LU8
tBi/UzZzSRCRYlQrxEqtsUvs2TvFXC5q5WTme8Rghq2qkkdj+lfjUtIoisiWSOMkNSoZq3DA
kk7xHjjZWlXIGa59mjPzpbxcOA0EBYmBpyWYAChZbfS4kxEZINpSN5yrCi5htWwdvEriEsiB
2Qqd9jZTB+zFe3ssK0i2ORUrWtPW/JtflZ2y+tt1Oxd2sD3azK20y6W79vJw/kTfSyhurup4
64HGhRoiEukqBESt2Xc/DFdl8mLSylkZyxaSrEle+zCzXP3fPfiVY2DXIuaS5Y2U7u4sxtjt
5MQRuyiIFPdyGobgO6ynB5rfNwRCUK5ZBo9e7LMX7XJffiy5LAqCpevCDWHiu87kxIzsMqS6
4NIbBxd5at1id9z29vGzw//Z
--------------7PgLauRTfrFMSuSkkIZrH0nz
Content-Type: image/png; name="HTTPS://IBM.BIZ/BDQAJH"
Content-Disposition: inline; filename="HTTPS://IBM.BIZ/BDQAJH"
Content-Id: <part2.eRjrvMqn.5DxA7ehy@cleistech.it>
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAMgAAADICAYAAACtWK6eAAAABmJLR0QA/wD/AP+gvaeTAAAA
CXBIWXMAAC4jAAAuIwF4pT92AAAAB3RJTUUH5QsREAoxoj9qugAAABl0RVh0Q29tbWVudABD
cmVhdGVkIHdpdGggR0lNUFeBDhcAAANiSURBVHja7d1LbuQwDEDB8cD3v7KzyCYJAqMtiAzJ
rtqnPzYe1OBo5OO6rusf8Kv/LgEIBAQCAgGBgEBAICAQEAgIBBAIvOZ8+gfHcbT/0nfbz+6+
X/a2texrvXpdJtx3Kwj4iQUCAYGAQEAg0Ne588Uq/e/dSmPJiM9S6VpPvu9WEBAICAQEAgIB
gUB9Z9YbTRh1ru70rbR7uNL7dbjvVhAQCAgEBAICAYFAfadLsEfE+HTCQQlWEBAICAQQCAgE
BALRjHl/6HI+rdGxFQQEAgIBgYBAQCDAp7Qxb6XzW+90eexZpUfFTbjvVhAQCAgEBAICAYFA
X1vHvNN3ikbs9F0d105/xJwVBAQCAgGBgEAAgcCrjqv7dssqF3Jx1Blx+IJbagUBgYBAQCAg
EBAIvJPHu3krjTNXZY9BI3blrr5mxHfvsiN55btbQUAgIBAQCAgEBAL1Pd7NO2Hsuvr9sj/n
hGvdfYxtBQGBgEBAICAQEAjUt/XQhohdndm7QbN33obc1ELXpfv1tIKAQEAgIBAQCAgE6ksb
867KPmQg+3O+82i8wwjYCgICAYGAQEAgIBCoL+3Qhkpn865651FuxDVzNi/4iQUCAYEAAgGB
wA7nzherdMZulx2mXXblroo4R9fZvOAnFggEBAICAYEAXz0e81baldtlp+jqZ8neBZx9/5zN
C35igUBAIIBAQCCww9azeW/faMDIssvjxLocrOFsXvATCwQCAgEEAgKBHR7v5jXOrP+a2dez
y/2zgoBAQCAgEBAICARmStvN2+aCDD/zNnusXGmMbQUBgYBAQCAgEBAIzJS2m7eSu/Fil6l3
pZ2+k/+lwAoCAgGBgEBAICAQqO/c+WKVxn3Zjz2L+JyVrmelQzcyv4MVBAQCAgGBgEBAIFDf
mfVGXQ5DWP0OEQcldHmUmhUEBAIIBAQCAgGBwF86XYLvVseuXUbAEd999TXvVBk5W0FAICAQ
EAgIBAQC9RnzPhAxAr7T5e8iRrlVHiNnBQGBgEBAICAQEAjUlzbm7fKYruyzcrN3+kaMZCN2
3trNC35igUBAICAQQCDwqq1j3ulnu0bsdu1yzSqdg7z6dx7BBn5igUBAICAQEAjMdFxdttmC
FQQEAgIBgYBAQCCAQEAgIBAQCAgEBAItfQAWP4GprOsaxgAAAABJRU5ErkJggg==

--------------7PgLauRTfrFMSuSkkIZrH0nz--

--------------wuQE9zIoj0HIaLfqGkGbJIhe--