From: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Sami Imseih <samimseih(at)gmail(dot)com>, 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 16:21:38 |
Message-ID: | CAEudQAqjwmrfH+BDpFLGTJBGwQ5zO95PtRzf3KeXz9KeUOYLUg@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Em qua., 10 de set. de 2025 às 23:53, Michael Paquier <michael(at)paquier(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Álvaro Herrera | 2025-09-11 16:30:30 | Re: Foreign key isolation tests |
Previous Message | Tom Lane | 2025-09-11 16:18:40 | Re: ALTER DATABASE RESET with unexistent guc doesn't report an error |