gfphoenix78 commented on code in PR #1257:
URL: https://github.com/apache/cloudberry/pull/1257#discussion_r2232712597
##########
src/backend/executor/nodeModifyTable.c:
##########
@@ -99,8 +101,43 @@ static TupleTableSlot
*ExecPrepareTupleRouting(ModifyTableState *mtstate,
TupleTableSlot *slot,
ResultRelInfo **partRelInfo);
+typedef struct ModifiedLeafRelidsKey
+{
+ CmdType cmd;
+ Oid relid;
+
+} ModifiedLeafRelidsKey;
+
+typedef struct ModifiedLeafRelidsData
+{
+ ModifiedLeafRelidsKey key;
+} ModifiedLeafRelidsData;
+
+static uint32
+modified_leaf_hash(const void *key, Size keysize)
+{
+ Assert(keysize == sizeof(ModifiedLeafRelidsKey));
+ return DatumGetUInt32(hash_any((const unsigned char*) key,
Review Comment:
> Hmm… that seems unnecessary—no standard hash functions work that way. I
don’t plan to spend more time on this; the current code is good enough as is.
Most of these don’t even include assertions anyway.
An alternative way is to call memset of the key, see
https://github.com/postgres/postgres/blob/db6461b1c9aae122b90bb52430f06efb306b371a/src/backend/utils/cache/relfilenumbermap.c#L153
I'm sure the hash value is wrong if there is any possible uninitialized
padding bit in the key. The current key structure looks has no padding, but
we'd better have the compiler for this assumption.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
