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 по дате отправления:

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: heavily contended lwlocks with long wait queues scale badly
Следующее
От: Dilip Kumar
Дата:
Сообщение: Re: Segfault on logical replication to partitioned table with foreign children