| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
| Cc: | Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Subject: | Re: SUM(int2)/SUM(int4) do not detect overflow of the int8 accumulator |
| Date: | 2026-09-02 07:37:04 |
| Message-ID: | apfSIBu_Q6uAOrsP@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Sep 02, 2026 at 08:01:56AM +0200, Andrei Lepikhov wrote:
> In my mind, we should pay for CPU cycles only in practical cases. So, if this
> case deserves an overflow check, it should be an assertion that consumes no
> resources in production.
All the patterns you are showing imply direct function calls, which
don't really seem worth bothering about. Are any of these overflow
cases reachable using operators with dedicated casts? I would count
as OK even cases where the sum functions are used in a custom
aggregate, say with a SFUNC set to one of the paths you are pointing
at.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bertrand Drouvot | 2026-09-02 07:45:10 | Re: Offline data checksum changes can cause incorrect checksum state on standbys |
| Previous Message | Michael Paquier | 2026-09-02 07:25:29 | Re: [PATCH] Test coverage for pg_clear_attribute_stats() null arguments |