Peter Eisentraut writes:
> On 11.10.22 18:04, Tom Lane wrote:
>> 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_CHECK
On 11.10.22 18:04, Tom Lane wrote:
Peter Eisentraut 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
Peter Eisentraut 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
On 14.09.22 06:53, Tom Lane wrote:
I wrote:
It kind of feels that the argument order should be pointer, oldsize, size.
It feels even more strongly that people will get the ordering wrong,
whichever we choose. Is there a way to make that more bulletproof?
Actually ... an even-more-terrifyingly
I wrote:
> It kind of feels that the argument order should be pointer, oldsize, size.
> It feels even more strongly that people will get the ordering wrong,
> whichever we choose. Is there a way to make that more bulletproof?
Actually ... an even-more-terrifyingly-plausible misuse is that the
sup
Peter Eisentraut writes:
> I have another little idea that fits well here: repalloc0 and
> repalloc0_array. These zero out the space added by repalloc. This is a
> common pattern in the backend code that is quite hairy to code by hand.
> See attached patch.
+1 in general --- you've put your
I have another little idea that fits well here: repalloc0 and
repalloc0_array. These zero out the space added by repalloc. This is a
common pattern in the backend code that is quite hairy to code by hand.
See attached patch.
From fa611ecf7c8a7b99d37c77da66b421d2f9ebfec3 Mon Sep 17 00:00:00 200
On 12.09.22 15:49, Tom Lane wrote:
Peter Eisentraut writes:
On 09.09.22 22:13, Tom Lane wrote:
I think serious consideration should be given to back-patching the
0001 part (that is, addition of the macros). Otherwise we'll have
to remember not to use these macros in code intended for back-pat
Peter Eisentraut writes:
> On 09.09.22 22:13, Tom Lane wrote:
>> I think serious consideration should be given to back-patching the
>> 0001 part (that is, addition of the macros). Otherwise we'll have
>> to remember not to use these macros in code intended for back-patch,
>> and that'll be mighty
On 09.09.22 22:13, Tom Lane wrote:
Peter Eisentraut writes:
I have updated this patch set to rename the _obj() functions to
_object(), and I have dropped the _ptrtype() variants.
I have also split the patch to put the new API and the example uses into
separate patches.
This patch set seems
Robert Haas writes:
> On Fri, Aug 12, 2022 at 3:31 AM Peter Eisentraut
> wrote:
>> (Personally, I have always been a bit suspicious about using the name
>> palloc() without memory context semantics in frontend code, but I guess
>> this is wide-spread now.)
> I think it would be a good thing to a
Peter Eisentraut writes:
> I have updated this patch set to rename the _obj() functions to
> _object(), and I have dropped the _ptrtype() variants.
> I have also split the patch to put the new API and the example uses into
> separate patches.
This patch set seems fine to me, so I've marked it
On Fri, Aug 12, 2022 at 3:31 AM Peter Eisentraut
wrote:
> (Personally, I have always been a bit suspicious about using the name
> palloc() without memory context semantics in frontend code, but I guess
> this is wide-spread now.)
I think it would be a good thing to add memory context support to t
On 12.08.22 09:31, Peter Eisentraut wrote:
In talloc, the talloc() function itself allocates an object of a given
type. To allocate something of a specified size, you'd use
talloc_size(). So those names won't map exactly. I'm fine with
palloc_object() if that is clearer.
I think the _ptrty
On 27.07.22 01:58, David G. Johnston wrote:
Admittedly I'm still getting my head around reading pointer-using code
(I get the general concept but haven't had to code them)
- lockrelid = palloc(sizeof(*lockrelid));
+ lockrelid = palloc_ptrtype(lockrelid);
// This definitely seems like an
On 26.07.22 23:32, Tom Lane wrote:
1. Do we really want distinct names for the frontend and backend
versions of the macros? Particularly since you're layering the
frontend ones over pg_malloc, which has exit-on-OOM behavior?
I think we've found that notational discrepancies between frontend
and
On Tue, Jul 26, 2022 at 2:32 PM Tom Lane wrote:
>
> 2. I don't like the "palloc_ptrtype" name at all. I see that you
> borrowed that name from talloc, but I doubt that's a precedent that
> very many people are familiar with.
> To me it sounds like it might
> allocate something that's the size
Peter Eisentraut writes:
> On 17.05.22 20:43, Tom Lane wrote:
>> So I think Peter's got a good idea here (I might quibble with the details
>> of some of these macros). But it's not really going to move the
>> safety goalposts very far unless we make a concerted effort to make
>> these be the styl
On 17.05.22 20:43, Tom Lane wrote:
So I think Peter's got a good idea here (I might quibble with the details
of some of these macros). But it's not really going to move the
safety goalposts very far unless we make a concerted effort to make
these be the style everywhere. Are we willing to do th
Bharath Rupireddy writes:
> On Tue, May 17, 2022 at 5:11 PM Peter Eisentraut
> wrote:
>> This adds additional variants of palloc, pg_malloc, etc. that
>> encapsulate common usage patterns and provide more type safety.
> I see lots of instances where there's no explicit type-casting to the
> targ
On Tue, May 17, 2022 at 5:11 PM Peter Eisentraut
wrote:
>
> This adds additional variants of palloc, pg_malloc, etc. that
> encapsulate common usage patterns and provide more type safety.
>
> Examples:
>
> - result = (IndexBuildResult *) palloc(sizeof(IndexBuildResult));
> + result = palloc_ob
21 matches
Mail list logo
