Re: Expand palloc/pg_malloc API
От | Peter Eisentraut |
---|---|
Тема | Re: Expand palloc/pg_malloc API |
Дата | |
Msg-id | c4e0877b-e85c-f276-cda1-7539df9b84c7@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Expand palloc/pg_malloc API (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Expand palloc/pg_malloc API
|
Список | pgsql-hackers |
On 11.10.22 18:04, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes: >> On 14.09.22 06:53, Tom Lane wrote: >>> Actually ... an even-more-terrifyingly-plausible misuse is that the >>> supplied oldsize is different from the actual previous allocation. >>> We should try to check that. In MEMORY_CONTEXT_CHECKING builds >>> it should be possible to assert that oldsize == requested_size. >>> We don't have that data if !MEMORY_CONTEXT_CHECKING, but we could >>> at least assert that oldsize <= allocated chunk size. > >> I'm not very familiar with MEMORY_CONTEXT_CHECKING. Where would one get >> these values? > > Hmm ... the individual allocators have that info, but mcxt.c doesn't > have access to it. I guess we could invent an additional "method" > to return the requested size of a chunk, which is only available in > MEMORY_CONTEXT_CHECKING builds, or maybe in !MEMORY_CONTEXT_CHECKING > it returns the allocated size instead. I'm not sure whether that amount of additional work would be useful relative to the size of this patch. Is the patch as it stands now making the code less robust than what the code is doing now? In the meantime, here is an updated patch with the argument order swapped and an additional assertion, as previously discussed.
Вложения
В списке pgsql-hackers по дате отправления: