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.98.2) (envelope-from ) id 1xD78E-00000000K6F-1I2n for pgsql-bugs@arkaria.postgresql.org; Sat, 03 Oct 2026 21:18:58 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xD78D-00000003FFB-1R5Y for pgsql-bugs@arkaria.postgresql.org; Sat, 03 Oct 2026 21:18:57 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xCluE-00000001TzZ-1iHZ for pgsql-bugs@lists.postgresql.org; Fri, 02 Oct 2026 22:39:06 +0000 Received: from mahout.postgresql.org ([2001:4800:3e1:1::227]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xCluC-000000004re-3uWT for pgsql-bugs@lists.postgresql.org; Fri, 02 Oct 2026 22:39:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Message-ID:Date:Reply-To:Cc:From:To:Subject: Content-Transfer-Encoding:MIME-Version:Content-Type:Sender:Content-ID: Content-Description:In-Reply-To:References; bh=n+y1dCsDpSloawSfltG8KLU7AUIzb44miLxT8euRxVc=; b=lXLCQYcQ2Swh6CIYOKJdB9hPIv 7vdlW44eb77O5GQZmLaBx6wyDn6Vkkg5gi0AMwcjFVlMfSIXK94loMHyOyKr4OaKt0uD9ZIcW3H6g 1yLKa2trIPUdrwqInpdganXbUMr8WCNPFsOV9No5wJbwkXZrVkjEYAUumyAXH0q8J99pUvfMCVQGE wK06t1nZBows+InIXMwjsRIj4RZtiJc5kZ1suQWrQqwnFScV1E3IEeU46FWemJ9GALR0XT+S2t0zk 16BXKxeJGqhy7UdHaTkXSVBNhlwmbiKoILvel4yC+DJt9n8O7SVIXtKRSdhqOXicWRSKS67o7JHWM HakJ4y4Q==; Received: from wrigleys.postgresql.org ([2a02:16a8:dc51::60]) by mahout.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1xCluC-00000000JDC-2Kbr for pgsql-bugs@lists.postgresql.org; Fri, 02 Oct 2026 22:39:04 +0000 Received: from localhost ([127.0.0.1] helo=wrigleys.postgresql.org) by wrigleys.postgresql.org with esmtp (Exim 4.98.2) (envelope-from ) id 1xCluB-00000000sik-1zee for pgsql-bugs@lists.postgresql.org; Fri, 02 Oct 2026 22:39:03 +0000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: BUG #19741: `avg(double precision)` overflows on cancelling finite inputs whose mean is representable To: pgsql-bugs@lists.postgresql.org From: PG Bug reporting form Cc: theshallow27@gmail.com Reply-To: theshallow27@gmail.com, pgsql-bugs@lists.postgresql.org Date: Fri, 02 Oct 2026 22:38:39 +0000 Message-ID: <19741-01386c4f17e36788@postgresql.org> X-Auto-Response-Suppress: All Auto-Submitted: auto-generated List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk The following bug has been logged on the website: Bug reference: 19741 Logged by: Shallow Email address: theshallow27@gmail.com PostgreSQL version: 18.6 Operating system: Linux Description: =20 The arithmetic mean of two finite values, `1e154` and `-1e154`, is exactly zero. PostgreSQL's `avg(double precision)` raises an overflow instead. The same input's sum is zero and its numeric average is zero. The aggregate's shared float8 accumulation state appears to overflow while accumulating values used for variance, although `avg` needs only the count and sum for its final result. **Reproduction:** ```sql SELECT avg(x) FROM unnest(ARRAY[1e154, -1e154]::double precision[]) AS t(x); ``` **Actual result:** SQLSTATE `22003`, `value out of range: overflow`. Reference calculation: ```sql SELECT sum(x), avg(x::numeric) FROM unnest(ARRAY[1e154, -1e154]::double precision[]) AS t(x); -- 0 | 0 ``` **Expected result:** `avg(double precision)` should return `0` for these finite inputs rather than failing due to an intermediate value that does not contribute to the arithmetic mean.