Re: Expand palloc/pg_malloc API

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Expand palloc/pg_malloc API
Date: 2022-10-31 08:47:05
Message-ID: c4e0877b-e85c-f276-cda1-7539df9b84c7@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 11.10.22 18:04, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)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 Content-Type Size
v2-0001-Add-repalloc0-and-repalloc0_array.patch text/plain 10.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2022-10-31 08:48:29 Re: Segfault on logical replication to partitioned table with foreign children
Previous Message Dilip Kumar 2022-10-31 08:41:47 Re: heavily contended lwlocks with long wait queues scale badly