From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Reducing the chunk header sizes on all memory context types |
Date: | 2022-09-08 22:15:23 |
Message-ID: | 20220908221523.c2nsmn7cvsdqvxvn@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2022-09-08 14:10:36 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | samay sharma | 2022-09-08 22:26:38 | Re: [RFC] building postgres with meson - v11 |
Previous Message | Tom Lane | 2022-09-08 22:12:10 | Re: Fix gin index cost estimation |