On Thu, 3 Sept 2026 at 00:48, David Rowley <[email protected]> wrote: > > On Wed, 2 Sept 2026 at 23:36, Matthias van de Meent > <[email protected]> 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)
