public inbox for [email protected]
help / color / mirror / Atom feedFrom: 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: Fri, 20 Dec 2024 08:57:59 +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]>
At 19/12/24 22:47, Adrian Klaver wrote:
>
>
> On 12/19/24 11:40 AM, Enrico Schenone wrote:
>> Hello, my answers in line along your message ...
>> Thanks a lot again.
>>
>> Enrico
>>
>
>>> On 12/19/24 10:11, Enrico Schenone wrote:
>>>> Good day, Adrian.
>>>> 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.
>>>
>
>> The 4Js DVM (Dynamic Virtual Machine) is that one
>> https://4js.com/online_documentation/fjs-gas-manual-html/index.html#gas-topics/c_gas_what_is_dvm.htm...
>>
>>> In other words an Android client?
>>>
>> No, it is a runtime interpreter for Linux, Windows, IBM AIX, macOS
>> and other unix-like OSs. It ensures the portability of 4Js Genero
>> compiled programs (p-code) on several OS platforms.
>> 4Js Genero is a Low Code Application Platform. The programming
>> language, named "BDL - Business Development Language", is an
>> evolution of the Informix-4gl.
>> Compiled programs needs a runtime interpreter (DVM) to be executed.
>> The DVM embeds at low-level the DB drivers provided by several vendors,
>
> From previous post you mentioned:
>
> "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 "
>
> So are they building their own driver over libpq?
I think so.
They wrote ...
<
/The error “no connection to the server“ is definitively a PostgreSQL
error:/
/||/
/|./src/interfaces/libpq/fe-exec.c: libpq_append_conn_error(conn, "no
connection to the server");|/
/It is not normal that PostgreSQL client can connect to the server, do
some SQL with success and then the SQL connection gets dropped at the
next SQL statement execution. This is really suspicious./
>
>
>> and at BDL high level the application program can easily connect to
>> the major DBs on the market thanks to its ODI (Open Database Interface).
>>>> 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.
>>>
>>> That might be useful.
>>>
>> Please take a look to the attached text file, that is the full
>> failing session log (filtered from the debug5 PostgreSQL server log).
>
> This is where it falls off the rails, but I can't see why?:
>
> 2024-12-16 17:27:14.406 CET [2214722] cleistech@hh24odds_prod -
> 192.168.16.17900000676054e0.21cb42 LOCATION: ShowTransactionStateRec,
> xact.c:5510
> 2024-12-16 17:27:14.406 CET [2214722] cleistech@hh24odds_prod -
> 192.168.16.17900000676054e0.21cb42 STATEMENT: fetch forward 50 from cu6
> 2024-12-16 17:27:14.406 CET [2214722] cleistech@hh24odds_prod -
> 192.168.16.17900000676054e0.21cb42 LOG: 00000: statement: fetch
> forward 50 from cu6
> 2024-12-16 17:27:14.406 CET [2214722] cleistech@hh24odds_prod -
> 192.168.16.17900000676054e0.21cb42 LOCATION: exec_simple_query,
> postgres.c:1073
> 2024-12-16 17:27:14.406 CET [2214722] cleistech@hh24odds_prod -
> 192.168.16.17900000676054e0.21cb42 DEBUG: 00000: CommitTransaction(1)
> name: unnamed; blockState: STARTED; state: INPROGRESS, xid/subid/cid:
> 0/1/0
>
> 2024-12-16 17:27:14.406 CET [2214722] cleistech@hh24odds_prod -
> 192.168.16.17900000676054e0.21cb42 LOCATION: ShowTransactionStateRec,
> xact.c:5510
> 2024-12-16 17:27:14.406 CET [2214722] cleistech@hh24odds_prod -
> 192.168.16.17900000676054e0.21cb42 STATEMENT: fetch forward 50 from cu6
> 2024-12-16 17:27:14.407 CET [2214722] cleistech@hh24odds_prod -
> 192.168.16.17908006676054e0.21cb42 LOG: 08006: could not receive data
> from client: Connessione interrotta dal corrispondente
>
Yes, at 2024-12-16 17:27:14.407
This seems to match exactly with the error XX001 reported by the client
application.
>>>> Thanks again and best regards.
>>>> Enrico
>
>
Best regards.
Enrico
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