Re: damage control mode - Mailing list pgsql-hackers

From Robert Haas
Subject Re: damage control mode
Date
Msg-id 603c8f071002070527j1dada7cdseb42e7cbc71bf71a@mail.gmail.com
Whole thread Raw
In response to Re: damage control mode  (Josh Berkus <josh@agliodbs.com>)
Responses Re: damage control mode
List pgsql-hackers
On Sun, Feb 7, 2010 at 1:38 AM, Josh Berkus <josh@agliodbs.com> wrote:
>> I think it might be time to revisit this issue.  SR is in, and we have
>> a week left in the CF, and we have all of the above patches plus 5
>> small ones left to deal with.  rbtree is close to being committable, I
>> think; knngist has not been reviewed yet; you (Tom) have claimed the
>> frame options patch but I haven't seen any update on it in a while; I
>> doubt either of the other two are ready to commit but I'm not sure how
>> far they have to go.
>
> I think, as previously discussed, that we should bounce knngist.    It's
> a complex patch and nobody saw anything of it until Jan 15, so I don't
> feel bad about it.  Mark Cave-Ayland was going to review it, but
> apparently felt that rbtree was the higher priority.

rbtree is a prerequisite for knngist.  point_ops was too.  I think
we're going to get rbtree done yet, but the main patch seems out of
reach.  There's no way it's going to go in without both pre-commit and
post-commit changes, and I don't think we have time for that now.

> Also, this one:
> Provide rowcount for utility SELECTs
> ... based on your last review does not look anywhere near ready.

I wouldn't worry about that one.  It's a small patch.  It's not going
to suck a lot of anyone's time; it'll either make it, or not.

> We know the following because of endless discussion on -hackers; what
> these patches seem to be suffering from is endless arguments over
> relatively minor points, it just requires someone to make a decision on
> implementation method:
> Add on_trusted_init and on_untrusted_init to plperl

I think this one is in pretty good shape.  I think the ball is Andrew
Dunstan's court to commit it, or not.

> Faster CREATE DATABASE by delaying fsync

Too much attempt to design an abstraction layer for things we can't
abstract; not enough doing something that is good enough for now.
Let's just put in something that's not particularly abstract and we
can rearrange later.

> For the rest, can we just have reviewer reports on readiness?
> Writeable CTEs

This was marked ready by the reviewer a long time ago; but that was
considerably over-optimistic, as the recent comments on that thread
attest.  A major feature without documentation is by definition not
ready.

> Package namespace and Safe init cleanup for plperl

I think this is close. Another one for Andrew Dunstan to make the
call, I believe.

> More frame options in window functions

Not sure.

> Fix large object support in pg_dump

Doesn't matter because this one is an open item.  I'm hoping Itagaki
Takahiro is going to take the lead on this one because he committed
the prior patch that created the situation we're now trying to fix.

> Actually, looking at that list, I think we're in pretty darned good
> shape.  That's a pretty small list of things left to commit.  Keep in
> mind that last year at this time (week 3 of CF-last) we still had over a
> dozen patches completely unreviewed!

Unfortunately, we haven't been very successful this time in attracting
non-committer reviewers.  Only about 20% of the committed patches are
listed as having been reviewed by a non-committer.  Still, I agree
with your overall conclusion.

...Robert


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: damage control mode
Next
From: Robert Haas
Date:
Subject: Re: Hot standby documentation