Re: Refactoring speculative insertion with unique indexes a little - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: Refactoring speculative insertion with unique indexes a little
Date
Msg-id CAM3SWZThuSMqwnOaURb5uhSgZNdok9AwN47fZjnhJXDYNBYDSw@mail.gmail.com
Whole thread Raw
In response to Re: Refactoring speculative insertion with unique indexes a little  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Refactoring speculative insertion with unique indexes a little  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Fri, Dec 18, 2015 at 8:58 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> No, it's far too late to be pushing this into 9.5.  We are at RC1 now
> and hoping to cut a final release right after Christmas.  I think it's
> quite wrong to argue that these changes have no risk of destabilizing
> 9.5.  Nobody is exempt from having bugs in their code - not me, not
> you, not Tom Lane.  But quite apart from that, there seems to be no
> compelling benefit to having these changes in 9.5.  You say that the
> branches will diverge needlessly, but the whole point of having
> branches is that we do need things to diverge.  The question isn't
> "why shouldn't these go into 9.5?" but "do these fix something that is
> clearly broken in 9.5 and must be fixed to avoid hurting users?".
> Andres has said clearly that he doesn't think so, and Heikki didn't
> seem convinced that we wanted the changes at all.

It isn't true that Heikki was not basically in favor of this. This
should have been committed as part of the original patch, really.

I hope to avoid needless confusion about the documented (by the
official documentation) AM interface. Yes, that is

> I think it's a shame that we haven't gotten this patch dealt with just
> because when somebody submits a patch in June, it's not very nice for
> it to still be pending in December, but since this stuff is even
> further outside my area of expertise than the sorting stuff, and since
> me and my split personalities only have so many hours in the day, I'm
> going to have to leave it to somebody else to pick up anyhow.  But
> that's a separate issue from whether this should be back-patched.

Note that I've already proposed a compromise, even though I don't
think my original position was at all unreasonable. There'd be zero
real changes (only the addition of the new constant name,
documentation updates, comment updates, etc) under that compromise (as
against one change.).

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: A Typo in regress/sql/privileges.sql
Next
From: Peter Geoghegan
Date:
Subject: Re: Re: Reusing abbreviated keys during second pass of ordered [set] aggregates