| From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
|---|---|
| To: | sumedhpathak(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #19836: Backend crash with large hash partition modulus |
| Date: | 2026-11-09 00:10:27 |
| Message-ID: | CAApHDvpixagsAMdxZFUyj6-YSs7k7QVvZQZJY=oBMSYMpMLjmA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Sun, 8 Nov 2026 at 04:54, PG Bug reporting form
<noreply(at)postgresql(dot)org> wrote:
> The following SQL crashes PostgreSQL 20devel (72b9498df9a, macOS ARM64):
> CREATE TABLE parent (i integer) PARTITION BY HASH (i);
> CREATE TABLE p0 PARTITION OF parent
> FOR VALUES WITH (MODULUS 3, REMAINDER 0);
> CREATE TABLE p1 PARTITION OF parent
> FOR VALUES WITH (MODULUS 2147483646, REMAINDER 2);
Thanks for the report.
It seems fine to just do:
@@ -2919,8 +2919,8 @@ check_new_partition_bound(char *relname, Relation parent,
if (partdesc->nparts > 0)
{
- int
greatest_modulus;
- int remainder;
+ int64 greatest_modulus;
+ int64 remainder;
That'll prevent the wrap and allow the do/while loop to terminate when
remainder is >= greatest_modulus. Bumping greatest_modulus isn't
really required, but I did that because I thought it was neater to
keep them the same size.
I can patch this when the freeze is over.
David
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tatsuo Ishii | 2026-11-09 00:19:50 | Re: first_value()/nth_value() with IGNORE NULLS loop forever (EXCLUDE GROUP/TIES, frame past partition end, no ORDER BY) |
| Previous Message | David Rowley | 2026-11-08 23:07:45 | Re: BUG #19853: Memoize returns wrong rows when the join operator is hashable but its equality semantics differ from |