Re: Reducing the chunk header sizes on all memory context types - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Reducing the chunk header sizes on all memory context types
Date
Msg-id 20220908221523.c2nsmn7cvsdqvxvn@awork3.anarazel.de
Whole thread Raw
In response to Re: Reducing the chunk header sizes on all memory context types  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Reducing the chunk header sizes on all memory context types
List pgsql-hackers
Hi,

On 2022-09-08 14:10:36 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > If there is a finalfunc, they're typically going to return data from within
> > the current memory context, but could legitimately also return part of the
> > data from curaggcontext. Perhaps we could forbid that?
> 
> No, I don't think we can get away with that.  See int8inc() for a
> counterexample.

What I was suggesting a bit below the bit quoted above, was that we'd copy
whenever there's no finalfunc or if the finalfunc doesn't take an internal
parameter. And that finalfuncs returning byref with an internal parameter can
be expected to return memory allocated in the right context (which we of
course could check with an assert).  It's not super satisfying - but I don't
think it'd have the problem you describe above.

Alternatively we could add a column to pg_aggregate denoting this. That'd only
be permissible to set for a superuser presumably.


This business with interpreting random memory as a palloc'd chunk seems like a
fundamentally wrong approach worth incurring some pain to fix.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fix gin index cost estimation
Next
From: samay sharma
Date:
Subject: Re: [RFC] building postgres with meson - v11