Re: An oversight in ExecInitAgg for grouping sets

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

In response to

Browse pgsql-hackers by date

  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