Hello.
At Wed, 5 Feb 2020 13:09:48 -0500, Robert Haas <robertmhaas@gmail.com> wrote in
> On Wed, Feb 5, 2020 at 12:15 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > The core problem that I'm unhappy about is that what you want to do
> > adds cognitive burden (including an increased risk of mistakes) and
> > extra debugging commands in common cases around inspecting memory
> > contexts in a debugger. Sure, it's not a fatal problem, but it's
> > still a burden. I judge that putting an enum into the struct would
> > greatly reduce that burden at very small cost.
>
> I respect that, but I disagree. I think the annoyance and strangeness
> factor of the enum is pretty high for third-party code that wants to
> use this, because deliberately concocting an out-of-range value for an
> enum is really odd. And I think the gain in debuggability is pretty
> low, because even if the enum seems to have the expected value, you
> still don't really know that things are OK unless you check the magic
> number and the methods field, too. On the other hand, I don't inspect
> memory contexts in a debugger all that often, and it sounds like you
> do, or you presumably wouldn't feel so strongly about this.
I agree that "deliberately concocting an out-of-(enum-)range value" is
odd. Regardless of the context type is in (or out-of?) enum or not,
there's no arbitrator of type numbers for custom allocators. If any,
it would be like that for LWLock tranches, but differently from
tranches, an allocator will fill the method field with the *correct*
values and works correctly even having a bogus type number. That is,
such an arbitration system or such type ids are mere a useless burden
to custom allocators, and such concocted (or pseudo-random) type
numbers don't contribute debuggability at all since it cannot be
distinguished from really-bogus numbers on its face.
Since we rarely face custom allocators, I think it's enough that we
have enum types for in-core allocators and one "CUSTOM". For the
"CUSTOM" allocators, we need to look into cxt->methods->name if we
need to identify it but I don't think it's too bothering as far as we
need to do that only for the need.
> We might have to see if anybody else has an opinion. I'd rather do it
> your way than no way, but I feel like it's such a strange design that
> I'd be afraid to commit it if anyone other than you had suggested it,
> for fear of having you demand an immediate revert and, maybe, the
> removal of some of my less important limbs.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
