Re: Bogus sizing parameters in some AllocSetContextCreate calls - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Bogus sizing parameters in some AllocSetContextCreate calls
Date
Msg-id 20160827194010.yigyqst5c5s2mfig@alap3.anarazel.de
Whole thread Raw
In response to Re: Bogus sizing parameters in some AllocSetContextCreate calls  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Bogus sizing parameters in some AllocSetContextCreate calls  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2016-08-27 15:36:28 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2016-08-27 14:08:44 -0400, Tom Lane wrote:
> >> Barring objection, I propose to make these changes in HEAD and 9.6.
> 
> > I think we might also / instead want to think about replacing a lot of
> > those AllocSetContextCreate with a wrapper function. Currently is really
> > rather annoying to experiment with switching the default allocator
> > out. And if we're touching all that code anyway ...
> 
> I do not see why you'd think that "switching the default allocator out"
> requires anything except making AllocSetContextCreate do something else.

Well yea. But given it's explicitly tied to aset.c that doesn't seem
like a sensible thing. DefaultContextCreate() or something (in mcxt.c),
which then calls AllocSetContextCreate, seems better to me.


> What is actually of interest, IMO, is making *some* contexts have a
> different allocator, and that is going to require case-by-case decisions
> anyway.  A blanket switch seems completely useless to me.

Don't think aset.c is actually that good, so I'm not convinced of
that. And even if it's just to verify that a special case allocator
actually works with more coverage...

Andres



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Bogus sizing parameters in some AllocSetContextCreate calls
Next
From: Tom Lane
Date:
Subject: Re: Bogus sizing parameters in some AllocSetContextCreate calls