Content-Type: multipart/alternative;
 boundary="------------nQv9pCmnKGg0r4h0QT7BhSzZ"
Message-ID: <282c2a48-bb12-4486-b03d-563523cac81b@cleistech.it>
Date: Thu, 19 Dec 2024 19:11:23 +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>
 <6ce80aaa-970b-4432-938a-39a07f811599@cleistech.it>
 <9f60eb26-7d34-4228-bd78-74c6deb90e54@aklaver.com>
Content-Language: it
In-Reply-To: <9f60eb26-7d34-4228-bd78-74c6deb90e54@aklaver.com>
Archived-At: <https://www.postgresql.org/message-id/282c2a48-bb12-4486-b03d-563523cac81b%40cleistech.it>
Precedence: bulk

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

Good day, Adrian.
I get the error inside the program by catching the exception and logging=20
it with diagnostic info provided by the DVM (a runtime interpreter=20
similar in concept to a JVM) that embed the PG driver.

This is the fragment of the source code=C2=A0 where the error occurs ...=20
comments are in blue color

# composing the query string with hardcoded WHERE part. In other cases=20
the query is parametric and values are passed with the FOREACH (FOREACH=20
... USING <argument list> ...)
LET l_qry =3D "SELECT * FROM quote_forn "||
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 " WHE=
RE evento_id=C2=A0 =3D "||t_qtf.evento_id||
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 " and=
 bt_id =3D "||idhh_bt

PREPARE q_stm FROM l_qry
DECLARE c_cur CURSOR FOR q_stm
TRY
 =C2=A0=C2=A0=C2=A0 LET c_qtf =3D ar_qtforn.getLength()
 =C2=A0=C2=A0=C2=A0 LET j =3D c_qtf

# FOREACH is a code structure who simplifies the OPEN/FETCH/CLOSE=20
structure. It is translated at runtime to OPEN cursor ... FETCH rows ...=20
CLOSE cursor.
 =C2=A0=C2=A0=C2=A0 FOREACH c_cur INTO r_qtf.*
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FOR v =3D 1 TO c_qtf
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IF ..=
. ... THEN ... ... END IF
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 END FOR
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LET j =3D j + 1
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LET ar_qtforn[j].id=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D r_qtf.id
 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ... ...
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 ... ...
 =C2=A0=C2=A0=C2=A0 END FOREACH

CATCH
 =C2=A0=C2=A0=C2=A0 LET str_msg =3D "Some error message ... event: ", t_q=
tf.evento_id, "=20
has failed. ", SQLERRMESSAGE, " - SQLSTATE: ", SQLSTATE # SQLSTATE is a=20
predefined variable containing the native PG SQLSTATE
# Write an application log line (the one I have sent to you inside the=20
cross log comparison along the timeline)
 =C2=A0=C2=A0=C2=A0 CALL GesLog(NULL, 1, str_msg)

END TRY
... ...
... ...

After that the program tries a single-row SELECT on a table just to=20
check if it is still able to get data from DB, and it fails with=20
*SQLSTATE XX000* (what you see into the log fragment one millisecond=20
after the server log reports error *08003*).

In some cases the query can be very complex and in other very simple, it=20
seems doesn't matters.
As you can see the code is very simple, but 999 times it works fine and=20
one time it fail returning *XX001* for minutes, and in the meantime a=20
lot of SQL operations including FETCH cursor works well.

I can't give you info on what the DVM does at low level, but I can send=20
you the distinct full session log fragment at server side, where it is=20
quite easy to understand how the DVM translates the program's SQL=20
queries end what PostgreSQL does.
May I give you any other info ?
Do you think it can be useful to include in this thread the 4Js Suppory=20
guys ?

Thanks again and 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 17:34, Adrian Klaver ha scritto:
> On 12/18/24 23:52, Enrico Schenone wrote:
>> Good day, Adrian.
>> First of all I thank-you for you answer.
>
>> 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=20
>> only fetch errors).
>> This happens sometimes also in system with no (or low) stress=20
>> situations.
>>
>> One of things I don't understand is why at client side I get the=20
>> XX001 error on the FETCH (normally the first fetch) while at server=20
>> side I heve no error related to the fetch forward ?
>
> Where are you fetching the client error messages from?
>
>> Another is why in the meantime no other client application report an=20
>> error, considering that there may be several parallel instances of=20
>> the same client application ?
>> And finally why after seconds or minutes the same process newly=20
>> instantiated works with no more errors ?
>
> Answers to this and the below is going to need the client code.
>
>>
>> I can suppose that the client closes the connection once got the=20
>> XX001 error, but I can't say why it receives this error while it is=20
>> 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=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=C2=A0 postgresql-client-16:amd64/jammy-pgdg 16.5-1.=
pgdg22.04+1=20
>> upgradeable to 16.6-1.pgdg22.04+1
>> =C2=A0=C2=A0=C2=A0=C2=A0 postgresql-client-common:all/jammy-pgdg 262.p=
gdg22.04+1=20
>> 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 =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=20
>>>> 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=20
>>> time 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
>>>>
>>>
>>
>

--------------nQv9pCmnKGg0r4h0QT7BhSzZ
Content-Type: multipart/related;
 boundary="------------z94O7T1orr8yaaQs0F9oPwgj"

--------------z94O7T1orr8yaaQs0F9oPwgj
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>
    I get the error inside the program by catching the exception and
    logging it with diagnostic info provided by the DVM (a runtime
    interpreter similar in concept to a JVM) that embed the PG driver.<br=
>
    <br>
    This is the fragment of the source code=C2=A0 where the error occurs =
...
    comments are in blue color<br>
    <br>
    <font face=3D"monospace"><font size=3D"4" color=3D"#1a5fb4"># composi=
ng
        the query string with hardcoded WHERE part. In other cases the
        query is parametric and values are passed with the FOREACH
        (FOREACH ... USING &lt;argument list&gt; ...)</font><br>
      <font size=3D"4">LET l_qry =3D "SELECT * FROM quote_forn "||<br>
        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 " WHERE evento_id=C2=A0 =3D "||t_qtf.evento_id||<br>
        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 " and bt_id =3D "||idhh_bt<br>
        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 <br>
        PREPARE q_stm FROM l_qry<br>
        DECLARE c_cur CURSOR FOR q_stm<br>
        TRY =C2=A0<br>
        =C2=A0=C2=A0=C2=A0 LET c_qtf =3D ar_qtforn.getLength() <br>
        =C2=A0=C2=A0=C2=A0 LET j =3D c_qtf <br>
        <br>
        =C2=A0=C2=A0=C2=A0 <font color=3D"#1a5fb4"># FOREACH is a code st=
ructure who
          simplifies the OPEN/FETCH/CLOSE structure. It is translated at
          runtime to OPEN cursor ... FETCH rows ... CLOSE cursor.</font><=
br>
        =C2=A0=C2=A0=C2=A0 FOREACH c_cur INTO r_qtf.*<br>
        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 FOR v =3D 1 TO c_qtf<b=
r>
        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 IF ... ... THEN ... ... END IF<br>
        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 END FOR <br>
        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LET j =3D j + 1 <br>
        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 LET ar_qtforn[j].id=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =3D r_qtf.id<br>
        =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ... ...<br>
        =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 ... ...<br>
        =C2=A0=C2=A0=C2=A0 END FOREACH=C2=A0 =C2=A0<br>
        <br>
        CATCH<br>
        =C2=A0=C2=A0=C2=A0 LET str_msg =3D "Some error message ... event:=
 ",
        t_qtf.evento_id, " has failed. ", SQLERRMESSAGE, " - SQLSTATE:
        ", SQLSTATE <font color=3D"#1a5fb4"># SQLSTATE is a predefined
          variable containing the native PG SQLSTATE</font><br>
        =C2=A0=C2=A0=C2=A0 <font color=3D"#1a5fb4"># Write an application=
 log line (the
          one I have sent to you inside the cross log comparison along
          the timeline)</font><br>
        =C2=A0=C2=A0=C2=A0 CALL GesLog(NULL, 1, str_msg)<br>
        <br>
        END TRY <br>
        ... ...<br>
        ... ...<br>
        <br>
        After that the program tries a single-row SELECT on a table just
        to check if it is still able to get data from DB, and it fails
        with <b>SQLSTATE XX000</b> (what you see into the log fragment
      </font></font><span class=3D"HwtZe" lang=3D"en"><span
        class=3D"jCAhz ChMk0b"><span class=3D"ryNqvb">one millisecond aft=
er
          the server log reports error <b>08003</b></span></span></span><=
font
      face=3D"monospace"><font size=3D"4">).<br>
      </font></font><br>
    In some cases the query can be very complex and in other very
    simple, it seems doesn't matters.<br>
    As you can see the code is very simple, but 999 times it works fine
    and one time it fail returning <b>XX001</b> for minutes, and in the
    meantime a lot of SQL operations including FETCH cursor works well.<b=
r>
    <br>
    I can't give you info on what the DVM does at low level, but I can
    send you the distinct full session log fragment at server side,
    where it is quite easy to understand how the DVM translates the
    program's SQL queries end what PostgreSQL does.<br>
    May I give you any other info ?<br>
    Do you think it can be useful to include in this thread the 4Js
    Suppory guys ?<br>
    <br>
    Thanks again and 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.uMuWvGgj.wEouHmC8@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.tye00ov6.ODmTIdxA@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 17:34, Adrian Klaver ha
      scritto:<br>
    </div>
    <blockquote type=3D"cite"
      cite=3D"mid:9f60eb26-7d34-4228-bd78-74c6deb90e54@aklaver.com">On
      12/18/24 23:52, Enrico Schenone wrote:
      <br>
      <blockquote type=3D"cite">Good day, Adrian.
        <br>
        First of all I thank-you for you answer.
        <br>
      </blockquote>
      <br>
      <blockquote type=3D"cite">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>
      </blockquote>
      <br>
      Where are you fetching the client error messages from?
      <br>
      <br>
      <blockquote type=3D"cite">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>
      </blockquote>
      <br>
      Answers to this and the below is going to need the client code.
      <br>
      <br>
      <blockquote type=3D"cite">
        <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;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.p=
ostgresql.org/docs/current/libpq.html">https://www.postgresql.org/docs/cu=
rrent/libpq.html</a> &gt;
        <br>
        <br>
        At client side I have installed the following PostgreSQL
        packages ...
        <br>
        <br>
        =C2=A0=C2=A0=C2=A0=C2=A0 postgresql-client-16:amd64/jammy-pgdg 16=
.5-1.pgdg22.04+1
        upgradeable to 16.6-1.pgdg22.04+1
        <br>
        =C2=A0=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>
        <br>
        *Enrico Schenone*
        <br>
        Software Architect
        <br>
        <br>
        *Cleis Tech s.r.l.* - <a class=3D"moz-txt-link-abbreviated" href=3D=
"http://www.gruppocleis.it">www.gruppocleis.it</a>
        <br>
        Sede di Genova, Via Paolo 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" href=3D"mailto:esch=
enone@cleistech.it">eschenone@cleistech.it</a>
        <br>
        <br>
        <a class=3D"moz-txt-link-rfc2396E" href=3D"https://gruppocleis.it=
">&lt;https://gruppocleis.it&gt;</a><a class=3D"moz-txt-link-rfc2396E" hr=
ef=3D"https://ibm.biz/BdqAJh">&lt;https://ibm.biz/BdqAJh&gt;</a>
        <br>
        <br>
        <a class=3D"moz-txt-link-rfc2396E" href=3D"https://ibm.biz/BdqAJh=
">&lt;https://ibm.biz/BdqAJh&gt;</a>
        <br>
        <a class=3D"moz-txt-link-rfc2396E" href=3D"https://ibm.biz/BdqAJh=
">&lt;https://ibm.biz/BdqAJh&gt;</a>
        <br>
        Il 19/12/24 00:11, Adrian Klaver ha scritto:
        <br>
        <blockquote type=3D"cite">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" hre=
f=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>
      </blockquote>
      <br>
    </blockquote>
    <br>
  </body>
</html>
--------------z94O7T1orr8yaaQs0F9oPwgj
Content-Type: image/jpeg; name="LogoCleis"
Content-Disposition: inline; filename="LogoCleis"
Content-Id: <part1.uMuWvGgj.wEouHmC8@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
--------------z94O7T1orr8yaaQs0F9oPwgj
Content-Type: image/png; name="HTTPS://IBM.BIZ/BDQAJH"
Content-Disposition: inline; filename="HTTPS://IBM.BIZ/BDQAJH"
Content-Id: <part2.tye00ov6.ODmTIdxA@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==

--------------z94O7T1orr8yaaQs0F9oPwgj--

--------------nQv9pCmnKGg0r4h0QT7BhSzZ--