Re: postponing some large patches to 9.2

From: David Fetter <david(at)fetter(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: postponing some large patches to 9.2
Date: 2011-02-08 18:02:08
Message-ID: 20110208180208.GB13514@fetter.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Feb 07, 2011 at 10:37:06PM -0500, Robert Haas wrote:
> On Mon, Feb 7, 2011 at 3:57 PM, Chris Browne <cbbrowne(at)acm(dot)org> wrote:
> > It sure looks to me like there are going to be a bunch of items that,
> > based on the recognized policies, need to get deferred to 9.2, and the
> > prospects for Sync Rep getting into 9.1 don't look notably good to me.
> >
> > It's definitely readily arguable that fairness requires that:
> >
> >  - Items not committable by 2011-02-15 be deferred to the 2011-Next fest
> >
> >   There are around 25 items right now that are sitting with [Waiting
> >   for Author] and [Returned with Feedback] statuses.  They largely seem
> >   like pretty fair game for "next fest."
> >
> >  - Large items that weren't included in the 2010-11 fest be considered
> >   problematic to try to integrate into 9.1
> >
> >   There sure seem to be some large items in the 2011-01 fest, which I
> >   thought wasn't supposed to be the case.
>
> This discussion reveals that it's time to start making some
> discussions about what can be accomplished for 9.1 and what must be
> postponed to 9.2.

Given how things worked, i.e. that people were not clear that 9.1
development had actually started, etc., I am again proposing that we
have one more CF starting March 15 to get this all cleaned up. Yes, I
know that wasn't the plan, but I also know that we're really, really
close on a whole bunch of things, some of which have been in the
offing for years at this point, and we risk giving people the
impression, if they don't already have it, that if they're not in the
"inner circle," their patches get lower priority no matter what their
merits.

> The big ones I think we should postpone are:
>
> - Range Types. This is a large patch which was submitted for the
> first time to the last CommitFest of the cycle, and the first version
> that had no open TODO items was posted yesterday, three-quarters of
> the way through that last CommitFest. Some good review has been done.
> While more is probably needed, I think we should feel good about
> what's been accomplished and mark this one Returned with Feedback.

This one's a product differentiator for PostgreSQL. We can own this
space for at least a year before it gets on any other RDBMS's roadmap.
That the work wasn't submitted until it was in pretty good shape is a
mark in Jeff's favor, not a reason to punt for another year.

> - ALTER EXTENSION UPGRADE. This is another large patch which was
> submitted for the first time to the last CommitFest of the cycle.
> The prerequisite patch to provide basic extension support has not
> been committed yet, although it sounds like that will happen soon.
> However, since that patch is undergoing a fair amount of surgery,
> it's reasonably certain that this will require significant rebasing.
> I think it would also be an overstatement to say that we have
> consensus on the design. My feeling is that, unless Tom thinks that
> failing to get this committed now is going to leave us with a mess
> later, we should mark this one Returned with Feedback and revisit it
> for 9.2.

If we're going to leave this out, we should probably pull EXTENSIONs
out entirely. Is that really where we want to go?

> - FOR KEY LOCK tables. This patch, unfortunately, has not gotten a
> lot of review. But it's a major, potentially destabilizing change
> that was, like the last two, submitted for the first time to the last
> CommitFest of the cycle. Even if we assume for the sake of argument
> that the code is unusually good for a feature of this type, I don't
> think it's the right time to commit something like this. I would
> argue for putting this off until 9.2, though preferably with a bit
> more review than it's gotten so far.
>
> The other remaining "big" patches are:
>
> - extension support for pg_upgrade. Tom is planning to have this
> committed within a day or so, per latest news.

See above.

> - synchronous replication. Based on some looking at this today, I am
> somewhat doubtful about the possibility of me or anyone else beating
> this completely into shape in time for 9.2, unless we choose to extend
> the deadline by several weeks.

+1 for extending that deadline. This is another product
differentiator, and we can have it as that for about a year if we make
sure it gets into 9.1.

> Simon said that he would have time to
> finish this in the next two weeks, but, as noted, the CommitFest is
> scheduled to be over in ONE week, and it looks to me like this is
> still pretty rough. However, there's a lot of good stuff in here, and
> I think it might be practical to get some portion of it committed even
> if we can't agree on all of it. I recommend we give this one a little
> more time to shake out before giving up on it.
>
> - SQL/MED. This patch unfortunately kind of stalled for a long time.
> However, I believe that Heikki is now working actively on the core
> patch, so I'm hopeful for some activity here soon.
>
> - Writeable CTEs. Tom has promised to look at this, but doesn't seem
> to be in a hurry.

This patch is about the worst in terms of "the inner circle" vs. our
open development model I referred to above. This, too, is a product
differentiator that we can really lead the standard with, and there's
no way to break any conceivable change to the standard with it.

What's the latest?

> - Per-column collation. This one has been lingering for a long time.
> But Noah Misch recently did a pretty thorough review, and it's now
> marked Ready for Committer. Peter, are you planning to commit this?

I think we're faced with the hard reality that we can't get a perfect
implementation of this in one go, as that would involve pulling the
"correctness" bits away from the OS-supplied libraries, etc., and into
PostgreSQL. I'm all for doing this eventually, and meanwhile getting
what's already done in.

> - The PL/python extravaganza. I'm not really clear where we stand
> with this. There are a lot of patches here.

Many of these are already a go. :)

Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2011-02-08 18:03:22 Re: Extensions versus pg_upgrade
Previous Message Robert Haas 2011-02-08 18:00:36 Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql