Re: Clear padding in PgStat_HashKey keys

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.

[0]: https://www.postgresql.org/message-id/flat/8c1e502a337e9557278f31abf877c321%40anastigmatix.net#4113241930633758cdbc22f49365806f

In response to

Responses

Browse pgsql-hackers by date

  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