Re: Is custom MemoryContext prohibited?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Kohei KaiGai <kaigai(at)heterodb(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Is custom MemoryContext prohibited?
Date: 2020-02-05 15:09:01
Message-ID: 2819.1580915341@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Hmm. What if we put a "const char *name" in the methods array? Then
> even if you couldn't print out the function pointers, you would at
> least see the name.

Yeah, that idea had occurred to me too. It'd definitely be better than
relying on the ability to interpret function pointers, and there might
be other uses for it besides manual debugging (eg if we had an outfuncs
function for MemoryContext, it could print that). So I'd be a bit in
favor of adding that independently of this discussion. I still think
that it'd be inconvenient for debugging, though, compared to having
an enum field right in the context. You'll have to do an extra step to
discover the context's type, and if you jump to the wrong conclusion
and do, say,
p *(AllocSetContext *) ptr_value
when it's really some other context type, there won't be anything
as obvious as "type = T_GenerationContext" in what is printed to
tell you you were wrong. So I really want to also have an enum
field of some sort, and it does not seem to me that there's any
compelling reason not to have one.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2020-02-05 15:12:52 Re: [Patch] Optimize dropping of relation buffers using dlist
Previous Message David Christensen 2020-02-05 14:35:30 Re: Documentation patch for ALTER SUBSCRIPTION