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 |
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 |