Re: Intermittent errors when fetching cursor rows on PostgreSQL 16 - Mailing list pgsql-general
From | Adrian Klaver |
---|---|
Subject | Re: Intermittent errors when fetching cursor rows on PostgreSQL 16 |
Date | |
Msg-id | 54689a6a-839c-44c4-90b5-b9692e8e7cb0@aklaver.com Whole thread Raw |
In response to | Re: Intermittent errors when fetching cursor rows on PostgreSQL 16 (Adrian Klaver <adrian.klaver@aklaver.com>) |
Responses |
Re: Intermittent errors when fetching cursor rows on PostgreSQL 16
|
List | pgsql-general |
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.html > >> 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? > 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 >>> Thanks again and best regards. >>> Enrico -- Adrian Klaver adrian.klaver@aklaver.com
pgsql-general by date: