Re: PgStat_HashKey padding issue when passed by reference
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Michael Paquier <michael@paquier.xyz>
Cc: Sami Imseih <samimseih@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-09-08T16:08:12Z
Lists: pgsql-hackers
Hi, On 2025-09-08 10:25:13 +0900, Michael Paquier wrote: > On Sat, Sep 06, 2025 at 10:35:58AM +0900, Michael Paquier wrote: > > One idea would be, for example, that keys used with simplehash should > > never have any padding at all, and we could force a check in the shape > > of a static assertion to force a failure when attempting to compile > > code that attempts to do so. That would give us a way to check in a > > broader way if some code path do that currently, scaling better with > > the expectations we could have in the whole tree or even out-of-core > > extension code. > > Doing some research here, I have noticed this one: > https://en.cppreference.com/w/cpp/types/has_unique_object_representations.html > > I was also wondering about some use of pg_attribute_packed() here, or > perhaps enforce a check based on offsetof() and the structure size, > but I doubt that any of that would be really portable across the > buildfarm. > > Another idea would be to make sure that the sizeof() of the structure > matches with the sum of the sizeof() for the individual fields in it. > That's cumbersome to rely on, still simpler. Perhaps we could do > something among these lines for pgstat_shmem.c, or just document that > the structure should never have any padding. I'd just add a comment mentioning that any padding bytes should be avoided. Greetings, Andres
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