| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Clear padding in PgStat_HashKey keys |
| Date: | 2024-11-04 07:25:00 |
| Message-ID: | Zyh2zD1fUJJggsCo@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Nov 03, 2024 at 04:25:41AM +0000, Bertrand Drouvot wrote:
> We are using sizeof(PgStat_HashKey) in pgstat_cmp_hash_key() and we compute the
> hash hash key in pgstat_hash_hash_key() using the PgStat_HashKey struct size as
> input: this lead to unexpected results if the keys contain random data in the
> padding bytes.
So you've seen that your patch was behaving weirdly once you have
added padding because the hash key size has been extended, leading to
relfilenode entries not being fetched when they should, right?
Perhaps it would be simpler to use a {0} like anywhere else for
PgStat_HashKey in pgstat_fetch_entry() and pgstat_drop_entry(), then
initialize the individual fields?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2024-11-04 08:26:37 | Re: Support LIKE with nondeterministic collations |
| Previous Message | jian he | 2024-11-04 07:16:35 | Re: general purpose array_sort |