Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tXNms-0060DY-Ew for pgsql-general@arkaria.postgresql.org; Mon, 13 Jan 2025 16:59:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tXNmr-00BZBY-1C for pgsql-general@arkaria.postgresql.org; Mon, 13 Jan 2025 16:59:37 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tXNmq-00BZBQ-IZ for pgsql-general@lists.postgresql.org; Mon, 13 Jan 2025 16:59:37 +0000 Received: from zproxy5.mail3d.it ([212.78.3.138]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tXNmo-000CjQ-2V for pgsql-general@lists.postgresql.org; Mon, 13 Jan 2025 16:59:36 +0000 Received: from zproxy5.mail3d.it (localhost.localdomain [127.0.0.1]) by zproxy5.mail3d.it (Postfix) with ESMTPS id 29A1C60BC1; Mon, 13 Jan 2025 17:59:33 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by zproxy5.mail3d.it (Postfix) with ESMTP id 0D5F360BA7; Mon, 13 Jan 2025 17:59:33 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy5.mail3d.it 0D5F360BA7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cleistech.it; s=1D99BE42-E8ED-11ED-9278-A8004466375A; t=1736787573; bh=JvuCX9/2wkRYr8s9+uos7KxbJiPr8FyGGf/IjoQrPG0=; h=Message-ID:Date:MIME-Version:To:From; b=lbgQyMc6gsq9OrG7cblNU1o1YQ4RZAMxNwKivrNN8NSNlbti5k+KAcz8WS4GFb0zQ JCyqIwDkuUevqms+DylGKEXaKzYItujlimZr6UE2eIUTP5Nd45yJLqpi04jUI2x5+a 0BtC0gPPHpDOLLgvnkgrl8kIF6Dy5Bt771HenHfKKz6yeJHWok8+s/lVvBBS2zm4Jr XfFQVYPYP107ZuIcnprelqhce3EQGu9gketz+L9jg9qF4VG6IcFA0hQQci+FR4tOaT i8SDPhwrml8L+6nRBXHkHzVEUvol5Sbh6A2xM4jolSSf7qBoqgfmd5ilzE66mYLbdr We7VT29UN9tng== Received: from zproxy5.mail3d.it ([127.0.0.1]) by localhost (zproxy5.mail3d.it [127.0.0.1]) (amavis, port 10026) with ESMTP id MzP1NqKfY37i; Mon, 13 Jan 2025 17:59:32 +0100 (CET) Received: from [192.168.0.20] (host-87-1-250-25.retail.telecomitalia.it [87.1.250.25]) by zproxy5.mail3d.it (Postfix) with ESMTPSA id AD32260BC1; Mon, 13 Jan 2025 17:59:32 +0100 (CET) Message-ID: Date: Mon, 13 Jan 2025 17:59:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Intermittent errors when fetching cursor rows on PostgreSQL 16 To: Adrian Klaver , pgsql-general@lists.postgresql.org Cc: Massimo Catti , Livio Pizzolo 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> <54689a6a-839c-44c4-90b5-b9692e8e7cb0@aklaver.com> <4efe42a2-789c-4957-a564-25199869f6ec@cleistech.it> <382a1eec-2069-4010-bbdb-37260a1a53a7@cleistech.it> Content-Language: it From: Enrico Schenone In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Il 13/01/25 17:19, Adrian Klaver ha scritto: > 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=20 >> production environment. >> I wrote a program that loads a temporary table, loads 2049 rows into=20 >> 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=20 >> on a lookup table as child. >> >> The program logic is the transposition of one fragment of several=20 >> production programs that was failing on cursors, and has to be=20 >> intended as a POC only. >> > > >> And Well, I'm quite confused: no error at all has been detected, not=20 >> only on the test programs but in the whole production system. The=20 >> error was completely disappeared. >> >> Then I have stopped the four tasks of the stress test leaving all=20 >> other services running for a week, and again no error at all. >> >> No setup was changed nor servers was rebooted, nor infrastructure has=20 >> been upgraded during the test period. > > You are absolutely sure about the above? I can say Yes. All test operations has been logged and verified against=20 the Postgresql log. The only component not under my control is the Provider's=20 Infrastructure, but=C2=A0 the infrastructure admin ensured me that no=20 operation at all has been made. I beleave him because it is a reliable=20 tecnician end a well known person. > >> >> As a result, at the moment I'm not understood not only Why & Where=20 >> the error was occurring, but also Why it is disappeared. > > Errors that 'fix' themselves are the most frustrating kind, as you=20 > know in the back of your mind they will likely pop up again. True, knocking again to my door ... I still can't beleave. > >> >> Anyone may feel free to give me his opinion. >> For the moment I'll make no other test unless the error is knocking=20 >> back to my door. > > That is all you can do. > >> >> *Enrico Schenone* >> Software Architect >> > Thanks a lot for your interest in sharing my strange experience. Best regards. Enrico *Enrico Schenone* Software Architect