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 |
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 |