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
-
Add Valgrind buffer access instrumentation.
- 1e0dfd166b3f 14.0 landed
-
Fix wrong merge resolution making pg_receivexlog fail in 9.2.
- 6b700301c36e 9.2.11 cited