Re: Clear padding in PgStat_HashKey keys
Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Jelte Fennema-Nio <postgres@jeltef.nl>
Cc: Michael Paquier <michael@paquier.xyz>, pgsql-hackers@lists.postgresql.org
Date: 2024-11-04T08:48:56Z
Lists: pgsql-hackers
Hi,
On Mon, Nov 04, 2024 at 09:27:43AM +0100, Jelte Fennema-Nio wrote:
> On Mon, 4 Nov 2024 at 08:25, Michael Paquier <michael@paquier.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.
Thank you both to look at it!
>
> So in many places we use memset or MemSet to clear the padding already:
>
> rg 'memset.*key' -S | wc -l
> 31
Yeah, and 9fd45870c1 did not touch some of them (like the one I mentioned up-thread
in LOCALLOCKTAG localtag in LockHeldByMe()).
> 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.
I think it's worth to do it now:
1/ for example, it's done in LOCALLOCKTAG localtag in LockHeldByMe() while
LOCALLOCKTAG does not contain padding (see up-thread).
2/ the one that will add padding could miss this thread and spend some time
to figure out why his patch does break existing stats.
3/ when dealing with structs that are used as hash key I think we should not wait
for padding to be introduced.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Commits
-
Clear padding of PgStat_HashKey when handling pgstats entries
- 6d5e6693ee6b 15.9 landed
- 925b3aa85700 16.5 landed
- 7f3b41ce48a5 17.1 landed
- 7d85d87f4d5c 18.0 landed