Re: satisfies_hash_partition crash

Ewan Young <kdbase(dot)hack(at)gmail(dot)com> 于2026年7月2日周四 10:08写道：
> 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.

Yes, you're right.

> 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.
How about this:
diff --git a/src/backend/partitioning/partbounds.c
b/src/backend/partitioning/partbounds.c
index 6fb150a8763..53c409cf2b1 100644
--- a/src/backend/partitioning/partbounds.c
+++ b/src/backend/partitioning/partbounds.c
@@ -4863,7 +4863,13 @@ satisfies_hash_partition(PG_FUNCTION_ARGS)
}
else
{
- ArrayType *variadic_array = PG_GETARG_ARRAYTYPE_P(3);
+ ArrayType *variadic_array;
+
+ /* Return false if the array is NULL. */
+ if (PG_ARGISNULL(3))
+ PG_RETURN_BOOL(false);
+
+ variadic_array = PG_GETARG_ARRAYTYPE_P(3);

/* allocate space for our cache -- just one
FmgrInfo in this case */
fcinfo->flinfo->fn_extra =

This way can avoid two get_fn_expr_variadic() calls if the last
argument is not combined into an array.
Thoughts?

--
Thanks,
Tender Wang