Re: PgStat_HashKey padding issue when passed by reference

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PgStat_HashKey padding issue when passed by reference
Date: 2025-09-11 15:21:45
Message-ID: CAA5RZ0tcMbN0mE+SfLfB94509XzaQqtcsM5B7VhH___mzgY5_A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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.

I don't see how this improves the situation, but will just make it more
difficult to add a new field that requires padding in the future.

If we are documenting either way, I rather that we just document the need
to pass a key by reference, which is the pattern used in other areas
( see pgss_store and entry_alloc in pg_stat_statements.c )

Others may have a different opinion.

--
Sami

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2025-09-11 15:24:27 Re: [PATCH] Hex-coding optimizations using SVE on ARM.
Previous Message Kirill Reshke 2025-09-11 15:00:03 Re: ALTER DATABASE RESET with unexistent guc doesn't report an error