Re: Expand palloc/pg_malloc API

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
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-11 16:04:20
Message-ID: 417848.1665504260@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dmitry Koval 2022-10-11 16:21:54 Re: Add SPLIT PARTITION/MERGE PARTITIONS commands
Previous Message Julien Rouhaud 2022-10-11 16:03:48 Re: Make EXPLAIN generate a generic plan for a parameterized query