Re: Shared buffer access rule violations?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>
Cc: Asim R P <apraveen(at)pivotal(dot)io>, Peter Geoghegan <pg(at)bowt(dot)ie>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, dkimura(at)pivotal(dot)io
Subject: Re: Shared buffer access rule violations?
Date: 2019-01-14 00:52:32
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> writes:
> On Thu, Aug 9, 2018 at 12:59 PM Asim R P <apraveen(at)pivotal(dot)io> wrote:
>> On Tue, Aug 7, 2018 at 7:00 PM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>>> I wonder if it would be a better idea to enable Valgrind's memcheck to
>>> mark buffers as read-only or read-write.

>> Basic question: how do you mark buffers as read-only using memcheck
>> tool? Running installcheck with valgrind didn't uncover any errors:

> Presumably with VALGRIND_xxx macros, but is there a way to make that
> work for shared memory?

> I like the mprotect() patch. This could be enabled on a build farm
> animal.

I think this is a cute idea and potentially useful as an alternative
to valgrind, but I don't like the patch much. It'd be better to
set things up so that the patch adds support for catching bad accesses
with either valgrind or mprotect, according to compile options. Also,
this sort of thing is gratitously ugly:

+ BufferMProtect(buf, PROT_NONE);

The right way IMO is to just have macro calls like

ProtectBuffer(buf, NO_ACCESS);

which expand to nothing at all if the feature isn't enabled by #ifdefs,
and otherwise to whatever we need it to do. (The access-type symbols
then need to be something that can be defined correctly for either

> I guess it would either fail explicitly or behave incorrectly
> for VM page size > BLCKSZ depending on OS, but at least on Linux/amd64
> you have to go out of your way to get pages > 4KB so that seems OK for
> a debugging feature.

What worries me more is that I don't think we try hard to ensure that
buffers are aligned on system page boundaries.

regards, tom lane

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Donald Dong 2019-01-14 01:23:45 Re: Ryu floating point output patch
Previous Message Andres Freund 2019-01-14 00:07:01 Reducing header interdependencies around heapam.h et al.