Incorrect comment for memset() on pgssHashKey?

From: Japin Li <japinli(at)hotmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Incorrect comment for memset() on pgssHashKey?
Date: 2023-06-27 04:32:10
Message-ID: MEYP282MB16696317B5DA7D0D92306149B627A@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Hi,

Commit 6b4d23feef introduces a toplevel field in pgssHashKey, which leads
padding. In pgss_store(), it comments that memset() is required when
pgssHashKey is without padding only.

@@ -1224,9 +1227,14 @@ pgss_store(const char *query, uint64 queryId,
query = CleanQuerytext(query, &query_location, &query_len);

/* Set up key for hashtable search */
+
+ /* memset() is required when pgssHashKey is without padding only */
+ memset(&key, 0, sizeof(pgssHashKey));
+
key.userid = GetUserId();
key.dbid = MyDatabaseId;
key.queryid = queryId;
+ key.toplevel = (exec_nested_level == 0);

/* Lookup the hash table entry with shared lock. */
LWLockAcquire(pgss->lock, LW_SHARED);

However, we need memset() only when pgssHashKey has padding, right?

--
Regrads,
Japin Li.

Attachment Content-Type Size
fix-incorrect-comment-for-pgss_store.patch text/x-diff 574 bytes

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2023-06-27 04:32:22 Re: ReadRecentBuffer() doesn't scale well
Previous Message Dilip Kumar 2023-06-27 04:12:28 Re: Improving btree performance through specializing by key shape, take 2