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:

Previous
From: Tom Lane
Date:
Subject: Re: Issue with pg_dump due to Schema OID Error
Next
From: Adrian Klaver
Date:
Subject: Re: cannot drop a tablespace which never exists in pg_tablespace