On 2/28/16 4:02 PM, Andres Freund wrote:
So, where to go from here? I'm acutely aware that we're hard up against
>the final 9.6 commitfest, and that we discourage major patches arriving
>so late in a devel cycle. But I simply couldn't get this done any faster.
>I don't really want to hold it over for the 9.7 devel cycle. It's been
>enough trouble maintaining this patch in the face of conflicting commits
>over the last year or so (it's probably still got bugs related to parallel
>query...), and there definitely are conflicting patches in the upcoming
>'fest. And the lack of this infrastructure is blocking progress on FDWs
>and some other things.
>
>So I'd really like to get this into 9.6. I'm happy to put it into the
>March commitfest if someone will volunteer to review it.
Hard. This is likely to cause/trigger a number of bugs, and we don't
have much time to let this mature. It's a change that we're unlikely to
be able to back-out if we discover that it wasn't the right thing to
integrate shortly before the release. On the other hand, this is a
major architectural step forward; one that unblocks a number of nice
features. There's also an argument to be made that integrating this now
is beneficial, because it'll cause less churn for patches being
developed while 9.6 is stabilizing.
Perhaps the best way to handle this would be to commit it to a branch
sooner rather than later. If things work out, that branch can become the
official beta. If not, in can become the basis for 9.7.
If nothing else it means that Tom isn't the only one stuck trying to
maintain this. Even if the branch is nothing but a means to generating a
patch for 9.7, having it in place makes it a lot easier for other
developers that need to to code against it.
While I'm promoting heresy... I imagine that this patch doesn't require
a catversion bump. Perhaps it would be worth doing a short-cycle major
release just to get this in. That might sound insane but since one of
the biggest obstacles to upgrading remains dealing with the on-disk
format, I don't think users would freak out about it.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
