Re: Expand palloc/pg_malloc API

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Aug 12, 2022 at 3:31 AM Peter Eisentraut
> <peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:
>> (Personally, I have always been a bit suspicious about using the name
>> palloc() without memory context semantics in frontend code, but I guess
>> this is wide-spread now.)

> I think it would be a good thing to add memory context support to the
> frontend. We could just put everything in a single context for
> starters, and then frontend utilities that wanted to create other
> contexts could do so.

Perhaps, but I think we should have at least one immediate use-case
for multiple contexts in frontend. Otherwise it's just useless extra
code. The whole point of memory contexts in the backend is that we
have well-defined lifespans for certain types of allocations (executor
state, function results, etc); but it's not very clear to me that the
same concept will be helpful in any of our frontend programs.

> There are difficulties, though. For instance, memory contexts are
> nodes, and have a NodeTag. And I'm pretty sure we don't want frontend
> code to know about all the backend node types. My suspicion is that
> memory context types really shouldn't be node types, but right now,
> they are. Whether that's the correct view or not, this kind of problem
> means it's not a simple lift-and-shift to move the memory context code
> into src/common. Someone would need to spend some time thinking about
> how to engineer it.

I don't really think that's much of an issue. We could replace the
nodetag fields with some sort of magic number and have just as much
wrong-pointer safety as in the backend. What I do take issue with
is moving the code into src/common. I think we'd be better off
just writing a distinct implementation for frontend. For one thing,
it's not apparent to me that aset.c is a good allocator for frontend
(and the other two surely are not).

This is all pretty off-topic for Peter's patch, though.

regards, tom lane