From: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Clear padding in PgStat_HashKey keys |
Date: | 2024-11-04 08:27:43 |
Message-ID: | CAGECzQS37h0twutb=kkS6v0rSnQ0vWxhVncqVNYoOTsv6gOmcw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 4 Nov 2024 at 08:25, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> 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?
{0} doesn't clear padding, it only sets all the fields to 0.
So in many places we use memset or MemSet to clear the padding already:
rg 'memset.*key' -S | wc -l
31
And even using memset in this manner isn't a standards compliant way
of handling this problem[0]. But it seems to have worked well enough
in practice.
Whether it's worth changing this now or only when we actually
introduce padding is another question though. But the code itself and
reasoning is sensible imo.
From | Date | Subject | |
---|---|---|---|
Next Message | wenhui qiu | 2024-11-04 08:30:36 | optimize the value of vacthresh and anlthresh |
Previous Message | Peter Eisentraut | 2024-11-04 08:26:37 | Re: Support LIKE with nondeterministic collations |