Re: PATCH: two slab-like memory allocators - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: PATCH: two slab-like memory allocators
Date
Msg-id CAB7nPqRSeXqEFXtvrivVMfmvjSapkKR=1xvY80OkuhP+a9TGSQ@mail.gmail.com
Whole thread Raw
In response to Re: PATCH: two slab-like memory allocators  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
On Sun, Oct 2, 2016 at 10:15 AM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> One more comment about GenSlab, particularly about unpredictability of the
> repalloc() behavior. It works for "large" chunks allocated in the AllocSet
> part, and mostly does not work for "small" chunks allocated in the
> SlabContext. Moreover, the chunkSize changes over time, so for two chunks of
> the same size, repalloc() may work on one of them and fail on the other,
> depending on time of allocation.
>
> With SlabContext it's perfectly predictable - repalloc() call fails unless
> the chunk size is exactly the same as before (which is perhaps a bit
> pointless, but if we decide to fail even in this case it'll work 100% time).
>
> But with GenSlabContext it's unclear whether the call fails or not.
>
> I don't like this unpredictability - I'd much rather have consistent
> failures (making sure people don't do repalloc() on with GenSlab). But I
> don't see a nice way to achieve that - the repalloc() call does not go
> through GenSlabRealloc() at all, but directly to SlabRealloc() or
> AllocSetRealloc().
>
> The best solution I can think of is adding an alternate version of
> AllocSetMethods, pointing to a different AllocSetReset implementation.

You guys are still playing with this patch, so moved to next CF with
"waiting on author".
-- 
Michael



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: GiST support for UUIDs
Next
From: Michael Paquier
Date:
Subject: Re: multivariate statistics (v19)