Re: Expand palloc/pg_malloc API - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Expand palloc/pg_malloc API
Date
Msg-id c4e0877b-e85c-f276-cda1-7539df9b84c7@enterprisedb.com
Whole thread Raw
In response to Re: Expand palloc/pg_malloc API  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Expand palloc/pg_malloc API  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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.

Attachment

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: heavily contended lwlocks with long wait queues scale badly
Next
From: Dilip Kumar
Date:
Subject: Re: Segfault on logical replication to partitioned table with foreign children