| From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
|---|---|
| To: | Tender Wang <tndrwang(at)gmail(dot)com> |
| Cc: | exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19405: Assertion in eval_windowaggregates() fails due to integer overflow |
| Date: | 2026-04-10 09:24:14 |
| Message-ID: | CAMbWs4-1J+WQFVR9=+gCgqugxoS=ecjiQ2t5GfLGDUgG7X2uqA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Wed, Apr 8, 2026 at 6:42 PM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> Here is the updated patch. I've added test cases for GROUPS mode with
> an overflow-inducing offset. These don't seem to produce visibly
> wrong results without the patch. I believe that is because the
> incremental nature of group pointer advancement happens to mask the
> misbehavior. But I think they are still worth having since signed
> integer overflow is undefined behavior in C.
>
> Regarding performance, I don't think this should be a concern.
> pg_add_s64_overflow compiles down to a native add+jo sequence on
> platforms with __builtin_add_overflow, and falls back to a couple of
> inlined comparisons on others. Either way, the cost seems negligible
> next to the per-row tuple store and aggregation work these functions
> already do.
I forgot to mention that I've committed and back-patched this fix.
- Richard
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matheus Alcantara | 2026-04-10 12:42:56 | Re: BUG: PostgreSQL 19devel throws internal opfamily error for FK with reordered referenced columns |
| Previous Message | Amit Langote | 2026-04-10 09:13:33 | Re: BUG: PostgreSQL 19devel throws internal opfamily error for FK with reordered referenced columns |