Re: [CORE] Restore-reliability mode

Jim Nasby <jim.nasby@bluetreble.com>

From: Jim Nasby <Jim.Nasby@BlueTreble.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Josh Berkus <josh@agliodbs.com>, Noah Misch <noah@leadboat.com>, Bruce Momjian <bruce@momjian.us>, Andres Freund <andres@anarazel.de>, Stephen Frost <sfrost@snowman.net>, Magnus Hagander <magnus@hagander.net>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, pgsql-core <pgsql-core@postgresql.org>
Date: 2015-06-05T16:06:12Z
Lists: pgsql-hackers
On 6/5/15 10:39 AM, Tom Lane wrote:
> The other side of that coin is that we might get useful comments from
> testers on how the feature ought to work.  I don't agree with the notion
> that all feature details must be graven on stone tablets before we start
> trying to get feedback from people outside the core development community.

+1

> The same point applies to the FDW C API questions, or to RLS, or to the
> "expanded objects" work that I did.  (I'd really love it if the PostGIS
> folk would try to use that sometime before it's too late to adjust the
> definition...)  Now, you could argue that people likely to have useful
> input on those issues are fully capable of working with git tip, and you'd
> probably be right, but would they do so?  As Simon says nearby, publishing
> an alpha/beta/whatever is our signal to the wider community that it's time
> for them to start paying attention.  I do not think they will look at 9.5
> until we do that; and I think it'll be our loss if they don't start
> looking at these things soon.

+1, but I also think we should have a better mechanism for soliciting 
user input on these things while design discussions are happening. ISTM 
that there's a lot of hand-waving that happens around use cases that 
could probably be clarified with end user input.

FWIW, I don't think the blocker here is git or building from source. If 
someone has that amount of time to invest it's not much different than 
grabbing a tarball.
-- 
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com


Commits

  1. Add Valgrind buffer access instrumentation.

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