Re: Lowering the ever-growing heap->pd_lower

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Lowering the ever-growing heap->pd_lower
Date: 2021-03-09 22:42:39
Message-ID: CAH2-WznDgHrc5B-J1s28cC26a429jMoe_SVk_ZMwSPj8t-tEuA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 9, 2021 at 1:54 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> It occurs to me that we should also mark the hole in the middle of the
> page (which includes the would-be LP_UNUSED line pointers at the end
> of the original line pointer array space) as undefined to Valgrind
> within PageRepairFragmentation().

It would probably also make sense to memset() the space in question to
a sequence of 0x7F bytes in CLOBBER_FREED_MEMORY builds. That isn't
quite as good as what Valgrind will do in some ways, but it has a
major advantage: it will usually visibly break code where the
PageRepairFragmentation() calls made by VACUUM happen to take place
inside another backend.

Valgrind instrumentation of PageRepairFragmentation() along the lines
I've described won't recognize the "hole in the middle of the page"
area as undefined when it was marked undefined in another backend.
It's as if shared memory is private to each process as far as the
memory poisoning/undefined-to-Valgrind stuff is concerned. In other
words, it deals with memory mappings, not memory.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2021-03-09 23:05:55 Re: POC: GROUP BY optimization
Previous Message Thomas Munro 2021-03-09 22:18:10 Re: Optimising latch signals