Feedback-ID: i76984098:Fastmail
Message-ID: <cdfa3e0c-a5cc-4f29-bcb7-72056ae03f1e@aklaver.com>
Date: Mon, 13 Jan 2025 08:19:11 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Intermittent errors when fetching cursor rows on PostgreSQL 16
To: Enrico Schenone <eschenone@cleistech.it>,
 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>
 <282c2a48-bb12-4486-b03d-563523cac81b@cleistech.it>
 <2645a89e-d661-4f2b-92b3-01154a78d535@aklaver.com>
 <e2332684-8d0f-47ba-a5ef-5b2b9c9f8cf0@cleistech.it>
 <54689a6a-839c-44c4-90b5-b9692e8e7cb0@aklaver.com>
 <4efe42a2-789c-4957-a564-25199869f6ec@cleistech.it>
 <e906a6a1-e97d-4bf7-afe3-21a430b3a944@aklaver.com>
 <ec5ce003-6ad9-4cfd-8186-6ca66f285ad3@cleistech.it>
 <b5e32ab4-2187-45f0-b360-47f82d481ff8@aklaver.com>
 <382a1eec-2069-4010-bbdb-37260a1a53a7@cleistech.it>
Content-Language: en-US
From: Adrian Klaver <adrian.klaver@aklaver.com>
In-Reply-To: <382a1eec-2069-4010-bbdb-37260a1a53a7@cleistech.it>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/cdfa3e0c-a5cc-4f29-bcb7-72056ae03f1e%40aklaver.com>
Precedence: bulk

On 1/13/25 00:45, Enrico Schenone wrote:
> Hello, Adrian.
> As I said days ago, I have arranged a kind of stress test in production 
> environment.
> I wrote a program that loads a temporary table, loads 2049 rows into 
> them from a baseline_table and finally declare two nested cursors.
> The first cursor is on the temp table as parent while the second is on a 
> lookup table as child.
> 
> The program logic is the transposition of one fragment of several 
> production programs that was failing on cursors, and has to be intended 
> as a POC only.
> 


> And Well, I'm quite confused: no error at all has been detected, not 
> only on the test programs but in the whole production system. The error 
> was completely disappeared.
> 
> Then I have stopped the four tasks of the stress test leaving all other 
> services running for a week, and again no error at all.
> 
> No setup was changed nor servers was rebooted, nor infrastructure has 
> been upgraded during the test period.

You are absolutely sure about the above?

> 
> As a result, at the moment I'm not understood not only Why & Where the 
> error was occurring, but also Why it is disappeared.

Errors that 'fix' themselves are the most frustrating kind, as you know 
in the back of your mind they will likely pop up again.

> 
> Anyone may feel free to give me his opinion.
> For the moment I'll make no other test unless the error is knocking back 
> to my door.

That is all you can do.

> 
> *Enrico Schenone*
> Software Architect
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com