Re: Restore-reliability mode

Alvaro Herrera <alvherre@2ndquadrant.com>

From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Noah Misch <noah@leadboat.com>
Cc: Peter Geoghegan <pg@heroku.com>, Simon Riggs <simon@2ndquadrant.com>, Bruce Momjian <bruce@momjian.us>, Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Stephen Frost <sfrost@snowman.net>, Magnus Hagander <magnus@hagander.net>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2015-07-27T14:12:31Z
Lists: pgsql-hackers
Noah Misch wrote:
> On Thu, Jul 23, 2015 at 04:53:49PM -0300, Alvaro Herrera wrote:
> > Peter Geoghegan wrote:
> > > On Sat, Jun 6, 2015 at 12:58 PM, Noah Misch <noah@leadboat.com> wrote:
> > > >   - Call VALGRIND_MAKE_MEM_NOACCESS() on a shared buffer when its local pin
> > > >     count falls to zero.  Under CLOBBER_FREED_MEMORY, wipe a shared buffer
> > > >     when its global pin count falls to zero.
> > > 
> > > Did a patch for this ever materialize?
> > 
> > I think the first part would be something like the attached.
> 
> Neat.  Does it produce any new complaints during "make installcheck"?

I only tried a few tests, for lack of time, and it didn't produce any.
(To verify that the whole thing was working properly, I reduced the
range of memory made available during PinBuffer and that resulted in a
crash immediately).  I am not really familiar with valgrind TBH and just
copied a recipe to run postmaster under it, so if someone with more
valgrind-fu could verify this, it would be great.


This part:

> > > >     Under CLOBBER_FREED_MEMORY, wipe a shared buffer when its
> > > >     global pin count falls to zero.

can be done without any valgrind, I think.  Any takers?

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


Commits

  1. Add Valgrind buffer access instrumentation.

  2. Fix wrong merge resolution making pg_receivexlog fail in 9.2.