Re: satisfies_hash_partition crash

On Thu, Jul 2, 2026 at 9:22 AM Tender Wang <tndrwang(at)gmail(dot)com> wrote:
>
> Robert Haas <robertmhaas(at)gmail(dot)com> 于2026年7月2日周四 03:11写道：
> >
> > Hi,
> >
> > This test case crashes the server for me:
> >
> > CREATE TABLE hp (a int) PARTITION BY HASH (a);
> > SELECT satisfies_hash_partition('hp'::regclass, 1, 0, VARIADIC NULL::int[]);
> >
> > I'm inclined to mostly blame my commit
> > f3b0897a1213f46b4d3a99a7f8ef3a4b32e03572, which fixed related problems
> > but overlooked this one. I think the fix should be simple, but since
> > that commit is from 2017, it will need to be back-patched all the way.
>
> Adding PG_ARGISNULL(3) to the beginning of the if() seems workable.

Thanks for looking at this!

I tried the PG_ARGISNULL(3) approach and ran into one subtlety I
thought worth mentioning:
it seems like the check can't go into the top-level if()
unconditionally. In a non-variadic call, a NULL
fourth argument is a valid NULL value for the first partition key, and
it looks like satisfies_hash_partition()
needs to keep returning the normal result there — that's how the
hash-partition CHECK constraint routes
rows with NULL key columns. Making it an unconditional false seems to
make hash partitions reject NULL rows.

I've attached a patch with a small regression test in case any of it
is useful, but I'm happy to leave the actual fix
to you.

Thanks again!

> And the comments need to be adjusted.
>
>
> --
> Thanks,
> Tender Wang
>
>

--
Regards,
Ewan Young