Re: BUG #19836: Backend crash with large hash partition modulus

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

In response to

Browse pgsql-bugs by date

  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