Re: Shared buffer access rule violations? - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Shared buffer access rule violations?
Date
Msg-id CAEepm=2_EnPc3n8=X_Q9UUQCGq_qU_A_nXSgHHFa4aBBDMQ88w@mail.gmail.com
Whole thread Raw
In response to Re: Shared buffer access rule violations?  (Asim R P <apraveen@pivotal.io>)
Responses Re: Shared buffer access rule violations?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Aug 9, 2018 at 12:59 PM Asim R P <apraveen@pivotal.io> wrote:
> On Tue, Aug 7, 2018 at 7:00 PM, Peter Geoghegan <pg@bowt.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. We've considered doing
> > something like that for years, but for whatever reason nobody followed
> > through.
>
> Basic question: how do you mark buffers as read-only using memcheck
> tool?  Running installcheck with valgrind didn't uncover any errors:
>
> valgrind --trace-children=yes pg_ctl -D datadir start
> make installcheck-parallel

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

I would like to do something similar with DSA, to electrify
superblocks and whole segments that are freed.  That would have caught
a recent bug in DSA itself and in client code.

-- 
Thomas Munro
http://www.enterprisedb.com


pgsql-hackers by date:

Previous
From: "Iwata, Aya"
Date:
Subject: RE: libpq debug log
Next
From: Michael Paquier
Date:
Subject: Re: when set track_commit_timestamp on, database system abort startup