Re: PgStat_HashKey padding issue when passed by reference
Ranier Vilela <ranier.vf@gmail.com>
From: Ranier Vilela <ranier.vf@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Sami Imseih <samimseih@gmail.com>, Andres Freund <andres@anarazel.de>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-09-11T16:21:38Z
Lists: pgsql-hackers
Em qua., 10 de set. de 2025 às 23:53, Michael Paquier <michael@paquier.xyz> escreveu: > On Mon, Sep 08, 2025 at 09:36:52PM -0500, Sami Imseih wrote: > > But my concern is the flexibility of this approach. If someone is to add > an > > OID field next, they will not be able to as that will be introducing > > padding. On the other hand, passing the key by reference and > > documenting the reason in pgstat_shmem.c will not lose this > > flexibility. > > I don't mind discarding the static assertion idea, but at the end what > counts for me here is that I don't want to sacrifice future changes in > the pgstats code that would always require passing around the hash key > by reference. > So I would just do like attached, documenting at the > top of PgStat_HashKey that we should not have padding in it, removing > three memset(0) calls that expected it. > Currently no compiler guarantees that static initialization will fill possible holes, something that *memset* guarantees. I think this change is unsafe. best regards, Ranier Vilela
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Document and check that PgStat_HashKey has no padding
- 3cd3a039da7f 19 (unreleased) landed