On Wed, May 4, 2016 at 3:51 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> The PostgreSQL 9.6 release management team has determined that there
>> is insufficient consensus at this time to revert any of the patches
>> mentioned in
>> because, with the exception of "snapshot too old", none of those
>> patches have attracted more than a single vote to revert. While
>> "snapshot too old" has attracted three votes to revert (Tom, Bruce,
>> Andres), one of those was on the grounds of not liking the feature i
>> general rather than any specific problem with the implementation (Tom)
>> and another gave no reason at all (Bruce). When originally proposed,
>> there was clear consensus that the feature was useful, so any revert
>> should be on the grounds that the current implementation is flawed.
> ... which, indeed, is precisely what Andres is asserting, no? I do
> not understand your conclusion.
Yes, and "asserting" is the right word, per my complaints in the first
> If the threshold is "more than one vote to revert", I'm sure that can
> be arranged. For the most part I think people have assumed that if
> one senior hacker complains about something, it's not really necessary
> for other people to duplicate that person's review effort. We don't
> have a surplus of manpower available for such things, and I believe
> most of us are going flat out right now anyway trying to get ready
> for beta. Duplicate reviews are hard to come by.
I don't think that >1 person saying something necessarily constitutes
a consensus, but 1 person saying something and 1 other person offering
a counter-argument sure doesn't. I have not yet read
and that may shed a different light on the situation, but as of a few
minutes ago the arguments thus far advanced for reverting any of the
patches I mentioned in
had convinced zero of three RMT members.
I believe that it is, and has long been, the community's general
policy that in doubtful cases, the discretion of the relevant
committer prevails. This may or may not be the best policy, but it is
usually how we operate.
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (email@example.com)
To make changes to your subscription: