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: