Re: malloc() in Dllist - Mailing list pgsql-hackers

From Tom Lane
Subject Re: malloc() in Dllist
Date
Msg-id 9392.958762632@sss.pgh.pa.us
Whole thread Raw
In response to malloc() in Dllist  (Karel Zak <zakkr@zf.jcu.cz>)
Responses Re: malloc() in Dllist  (Karel Zak <zakkr@zf.jcu.cz>)
List pgsql-hackers
Karel Zak <zakkr@zf.jcu.cz> writes:
>  I'm total confuse. I continue in query cache implementation and I want use
> Dllist routines, but what I see --- it hardly use malloc/free. Why? With
> this is a Dllist usage _very_ limited... (the catcache works with malloc? 
> --- hmm interesting)

I think the reason Dllist still uses malloc directly is that the
selfsame code is used by libpq, and there's no palloc in the frontend
environment.  This is pretty ugly of course.  It would probably be
better to give libpq its own copy of the routines (I don't think it
needs 'em all anyway, nor ought to be polluting application namespace
with global symbols that don't start with "pq") and then the backend's
version could use palloc.  But we'd have to look at all the callers to
be sure they have current memory context set to an appropriate thing.

>  Tom, assume you with some 'malloc_based_context' in your memory-management
> proposal?

It can't be *directly* malloc based if we want to ensure that pfree()
works regardless of context type.  We need that header with the
back-link to the context to be there always.  We could have a context
type where each chunk is always a separate malloc request, and palloc
is just a thin wrapper that adds the chunk header ... but I'm not sure
what for ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: Heaps of read() syscalls by the postmaster
Next
From: Oleg Bartunov
Date:
Subject: Re: Re: Heaps of read() syscalls by the postmaster