From: | David Rowley <dgrowleyml(at)gmail(dot)com> |
---|---|
To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: An oversight in ExecInitAgg for grouping sets |
Date: | 2023-04-11 13:17:55 |
Message-ID: | CAApHDvrdnkhA4qFVSb0he0VWNEhmosQvNraOGFqh86O1fE1pcA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 9 Jan 2023 at 22:21, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> One extra thing I noticed was that I had to add a new
> VALGRIND_MAKE_MEM_DEFINED in AllocSetAlloc when grabbing an item off
> the freelist. I didn't quite manage to figure out why that's needed as
> when we do AllocSetFree() we don't mark the pfree'd memory with
> NOACCESS, and it also looks like AllocSetReset() sets the keeper
> block's memory to NOACCESS, but that function also clears the
> freelists too, so the freelist chunk is not coming from a recently
> reset context.
It seems I didn't look hard enough for NOACCESS marking. It's in
wipe_mem(). So that explains why the VALGRIND_MAKE_MEM_DEFINED is
required in AllocSetAlloc.
Since this patch really only touches Valgrind macros, I don't really
feel like there's a good reason we can't still do this for v16, but
I'll start another thread to increase visibility to see if anyone else
thinks differently about that.
David
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2023-04-11 13:19:34 | Re: When to drop src/tools/msvc support |
Previous Message | Emre Hasegeli | 2023-04-11 12:58:05 | Re: Unnecessary confirm work on logical replication |