Clear padding in PgStat_HashKey keys

Hi hackers,

While working on a rebase for [0], I noticed some weird behavior on the stats.

The issue is that [0], in conjonction with b14e9ce7d5, does introduce padding in 
the PgStat_HashKey:

(gdb) ptype /o struct PgStat_HashKey
/* offset      |    size */  type = struct PgStat_HashKey {
/*      0      |       4 */    uint32 kind;
/*      4      |       4 */    Oid dboid;
/*      8      |       8 */    uint64 objid;
/*     16      |       4 */    RelFileNumber relfile;
/* XXX  4-byte padding   */

                               /* total size (bytes):   24 */
                             }

But, the keys are initialized that way:

"
PgStat_HashKey key = {.kind = kind,.dboid = dboid,.objid = objid,.relfile = refile};
"

which could lead to random data in the padding bytes.

We are using sizeof(PgStat_HashKey) in pgstat_cmp_hash_key() and we compute the
hash hash key in pgstat_hash_hash_key() using the PgStat_HashKey struct size as
input: this lead to unexpected results if the keys contain random data in the 
padding bytes.

Even if currently there is no issues, as without [0] there is no padding:

(gdb) ptype /o struct PgStat_HashKey
/* offset      |    size */  type = struct PgStat_HashKey {
/*      0      |       4 */    uint32 kind;
/*      4      |       4 */    Oid dboid;
/*      8      |       8 */    uint64 objid;

                               /* total size (bytes):   16 */
                             }

I think that we should ensure to $SUBJECT (to prevent unexpected results should
padding be introduced in the future).

For example we currently ensure the same for LOCALLOCKTAG localtag in LockHeldByMe()
while there is no padding:

gdb) ptype /o struct LOCALLOCKTAG
/* offset      |    size */  type = struct LOCALLOCKTAG {
/*      0      |      16 */    LOCKTAG lock;
/*     16      |       4 */    LOCKMODE mode;

                               /* total size (bytes):   20 */
                             }

So, please find attached a patch to $SUBJECT.

[0]: https://www.postgresql.org/message-id/flat/ZlGYokUIlERemvpB%40ip-10-97-1-34.eu-west-3.compute.internal

Looking forward to your feedback,

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com