Re: PgStat_HashKey padding issue when passed by reference - Mailing list pgsql-hackers

From Sami Imseih
Subject Re: PgStat_HashKey padding issue when passed by reference
Date
Msg-id CAA5RZ0saO_DfAxUFD_QSm804+Sm_-t+Sq67ESXq_q__eQgG9vw@mail.gmail.com
Whole thread Raw
In response to Re: PgStat_HashKey padding issue when passed by reference  (Michael Paquier <michael@paquier.xyz>)
Responses Re: PgStat_HashKey padding issue when passed by reference
List pgsql-hackers
> More suggestions or a better sentence are of course welcome.

> "NB: We assume that this struct contains no padding.  The 8 bytes
> allocated for the object ID are good enough to ensure the uniqueness
> of the hash key, hence the addition of new fields is not recommended."

That sounds correct. However, I see the no padding and the objid as separate
points. One could add a new field that does not introduce padding. So, I added
"Also, " for clarity.

"NB: We assume that this struct contains no padding.  Also, 8 bytes
 allocated for the object ID are good enough to ensure the uniqueness
of the hash key, hence the addition of new fields is not recommended."

Also, what about we also add the assert as done earlier in this thread [0]
to ensure that the struct indeed does not have padding?

+/*
+ * PgStat_HashKey should not have any padding. Checking that the structure
+ * size matches with the sum of each field is a check simple enough to
+ * enforce this policy.
+ */
+StaticAssertDecl((sizeof(PgStat_Kind) + sizeof(uint64) + sizeof(Oid)) ==
+ sizeof(PgStat_HashKey),
+ "PgStat_HashKey should have no padding");
+

[0] https://www.postgresql.org/message-id/aL9zo5X0MsSxO2pM%40paquier.xyz

--
Sami



pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Parallel heap vacuum
Next
From: Melanie Plageman
Date:
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)