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.96) (envelope-from ) id 1vQwwH-002oro-1F for pgsql-bugs@arkaria.postgresql.org; Thu, 04 Dec 2025 00:11:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vQwwF-00H9gG-0E for pgsql-bugs@arkaria.postgresql.org; Thu, 04 Dec 2025 00:11:15 +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.96) (envelope-from ) id 1vQwwE-00H9g8-2d for pgsql-bugs@lists.postgresql.org; Thu, 04 Dec 2025 00:11:15 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vQwwC-0030W4-34 for pgsql-bugs@lists.postgresql.org; Thu, 04 Dec 2025 00:11:14 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 5B40B6Js931690; Wed, 3 Dec 2025 19:11:06 -0500 From: Tom Lane To: Dean Rasheed cc: Oleg Ivanov , Laurenz Albe , pgsql-bugs@lists.postgresql.org Subject: Re: BUG #19340: Wrong result from CORR() function In-reply-to: <923070.1764802351@sss.pgh.pa.us> References: <19340-6fb9f6637f562092@postgresql.org> <4ab9867066e9545dd1a7e835a480bb0ecbe1a00d.camel@cybertec.at> <375068.1764696127@sss.pgh.pa.us> <434484.1764707203@sss.pgh.pa.us> <513345.1764717860@sss.pgh.pa.us> <531516.1764721052@sss.pgh.pa.us> <545890.1764725276@sss.pgh.pa.us> <923070.1764802351@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Wed, 03 Dec 2025 17:52:31 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <931688.1764807066.1@sss.pgh.pa.us> Date: Wed, 03 Dec 2025 19:11:06 -0500 Message-ID: <931689.1764807066@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk I wrote: > Poking at this, I soon found a test case where even with the separate > sqrt() calls we'd produce a result slightly outside [-1, 1] (running > this test over more values of x is sufficient). So now I think we > should do both the separate sqrt and the clamp. Per CI results, on some platforms the roundoff error is different from what I observe, producing a value just less than 1 rather than just more. That doesn't invalidate needing the clamp, but it does mean that we can't use that test case just like that. I'm inclined to remove the change of extra_float_digits, but keep the test case. regards, tom lane