Re: glist: _Generic wrapper for selective dlist/dclist usage

On Thu, 3 Sept 2026 at 00:48, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>
> On Wed, 2 Sept 2026 at 23:36, Matthias van de Meent
> <boekewurm+postgres(at)gmail(dot)com> wrote:
> > Attached is a patch that adds glist_* macros, which wrap several
> > dlist/dclist_* APIs, so that developers can use dlist/dclist
> > selectively in different environments, without significant visual
> > overhead in the code. I'm planning to use this in the Proxy memory
> > contexts over at [1].
>
> This feels like putting the cart before the horse. What purpose does
> maintaining a count in the dlist serve at all for [1]?

To check the consistency of the dlist, and with it, the consistency of
this part of the memory context's overall structure? It's the same
reason we have chunk->requested_size and checks to validate its
consistency with other information, and check the sum of allocated
memory against contex->mem_allocated in practically every mcm.check
implementation. Dlists don't inherently have an authorative indicator
of where every member exists or how many there are, and therefore
don't have much corruption protection if something goes wrong; all you
have is a progressively explored list of elements that you hope is
consistent and loops back to the list head.

> Last I looked
> at the 0004 patch on [1] you were only counting and asserting the
> count in debug builds. Since the count is not used for anything else,
> it seemed to me that all the assert was doing was verifying the count
> tracking was correct, and since that count tracking code only existed
> in debug builds, there was no point in it.

It makes a lot of sense to me to make sure that a linked list (when
that is critical to your data structure's integrity) has not
accidentally lost entries or received new ones unexpectedly. I don't
think it's much different from checking that the sum total of your
context's allocations adds up to context->mem_allocated, and that the
sentinel bytes haven't been overwritten. Yes, the condition should be
invariantly correct, but you prefer knowing that something was wrong
if that invariant was broken somehow.

And yes, debug builds are exactly where you add deep validation to
memory contexts, as that is when MCM->check is used and available.

> I think if you have a concrete proposal for your 0001 patch here,
> there should be a 0002 patch which uses the new macros for some
> legitimate reason. Otherwise, if the only legit reason is in [1], then
> this patch should be part of that series. At the moment, all this
> thread proposes to do is introduce dead code.

Every new API needs a first caller, sure. But in this case, right now,
I can't find _any_ uses of _Generic in our current headers, apart from
StaticAssertVariableIsOfType*, and a MSVC-specific macro for
pg_integer_constant_p. No real APIs are currently exposed with
_Generic -wrapping macros, hence why I started a separate thread to
accumulate interest and feedback on using this new C11 feature to
provide a simple unified API against two implementations that
developers may want to select between.

Kind regards,

Matthias van de Meent
Databricks (https://www.databricks.com)