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
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 |