| 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: | Whole Thread | Raw Message | 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 |