On Thu, Jul 2, 2026 at 9:22 AM Tender Wang <[email protected]> wrote: > > Robert Haas <[email protected]> 于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
v1-0001-Fix-crash-in-satisfies_hash_partition-with-NULL-vari.patch
Description: Binary data
