Thread: [HACKERS] 2017-03 Commitfest In Progress
The 2017-03 commitfest is now in progress. Here's the breakdown: Needs review: 128 Waiting on Author: 26 Ready for Committer: 26 Total: 180 If you are an author and have a patch in the "Waiting for Author" state please update it as soon as you can. Otherwise, jump in and start reviewing! -- -David david@pgmasters.net
On Thu, Mar 2, 2017 at 4:42 AM, David Steele <david@pgmasters.net> wrote: > The 2017-03 commitfest is now in progress. Here's the breakdown: > > Needs review: 128 > Waiting on Author: 26 > Ready for Committer: 26 > Total: 180 Not quite a record haul but close. -- Thomas Munro http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
Thomas Munro <thomas.munro@enterprisedb.com> writes:
> On Thu, Mar 2, 2017 at 4:42 AM, David Steele <david@pgmasters.net> wrote:
>> The 2017-03 commitfest is now in progress. Here's the breakdown:
>>
>> Needs review: 128
>> Waiting on Author: 26
>> Ready for Committer: 26
>> Total: 180
> Not quite a record haul but close.
Indeed. As usual, a depressingly large number of patches appeared out of
the woodwork in the last few days before the deadline, and more than a
couple of those seem to be clear violations of our rule about "no major
new features should first appear during the last commitfest".
I think we should have a discussion about which patches need to be booted
to the next CF (ie, first of the v11 cycle) without further attention now.
ISTM it would be quite unfair if patches that have been in the queue for
much longer fail to get into v10 because johnny-come-lately patches
consumed reviewer and committer bandwidth.
regards, tom lane
On Thu, Mar 2, 2017 at 6:58 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Indeed. As usual, a depressingly large number of patches appeared out of > the woodwork in the last few days before the deadline, and more than a > couple of those seem to be clear violations of our rule about "no major > new features should first appear during the last commitfest". Yes, there was an unfortunate amount of last-minute activity. Regrettably, pgsql-hackers has not yet found a way to eliminate procrastination from human nature. Actually, I had a draft patch for that, but I never got around to posting it. > I think we should have a discussion about which patches need to be booted > to the next CF (ie, first of the v11 cycle) without further attention now. > ISTM it would be quite unfair if patches that have been in the queue for > much longer fail to get into v10 because johnny-come-lately patches > consumed reviewer and committer bandwidth. I would actually rather start by having the opposite discussion: of the many patches that are current pending, which have been pending for such a long time that we will be doing particularly-severe injustice to the authors if we don't make a real effort to get them done? Here's a few that I would put into that category: Fix the optimization to skip WAL-logging on table created in the same transaction (originally submitted to CommitFest 2016-03) https://commitfest.postgresql.org/13/528/ Michael perhaps-unwisely set the committer on this one to Heikki, which led me and perhaps other committers to think he was going to take care of it. But he may not have intended to do that; it's best to let committers claim patches for themselves rather than assign them. That having been said, I think it's bad when a known data-corrupting bug goes unfixed for a year and a half. Unique Joins (originally submitted to CommitFest 2015-02) https://commitfest.postgresql.org/13/859/ Tom found some time to start looking at this in February and the tenor of the discussion seemed to indicate that agreement was not too far off, but then discussion died out. While I haven't reviewed this in detail, I think the performance gains are pretty significant and I'd like to see some of this work get committed if that is possible. SCRAM Authentication (originally submitted to CommitFest 2015-09) https://commitfest.postgresql.org/13/993/ This patch has been evolving until very recently, and maybe still, so it's maybe unfair to put it into the same category as the previous two, but I don't think anybody is going to be very happy about waiting another year for an alternative to MD5 authentication. Even though there's not, to my knowledge, an effective preimage attack for MD5, surely we want to have alternatives in case one is developed. That's not going to be something we can back-patch. Heikki did quite a bit of work to drive this forward, but seems to have had little time to push that work forward lately. I don't know if there's another committer who can pick this up. I initially thought I could help, but the fact that the thread has ended up a discussion of Unicode normalization has intimidated me a bit. Multivariate Statistics (originally submitted to CommitFest 2016-01) https://commitfest.postgresql.org/13/852/ Past the one year mark; more than two years since the first WIP version was posted. I am vaguely under the impression that we've hammered out the syntax issues here, but I'm not sure of it, and I think there's a bigger issue which doesn't seem to have been studied much: is this good math? Somebody who has studied the use of statistics in query planning more than I should have a well-considered opinion on that. amcheck (originally submitted to CommitFest 2016-03) https://commitfest.postgresql.org/13/561/ Anybody who thinks this isn't a good idea is living in a world quite different from mine. Whether the code has got problems, I don't know. Andres has expressed some interest in picking up this patch, but I'm not sure whether how committed he is to it (no pun intended). Parallel tuplesort (originally submitted to CommitFest 2016-09) https://commitfest.postgresql.org/13/690/ Heikki and I have both done a little work to move this forward, but it needs a lot more attention than it has gotten. As I see it, this patch touches on two worlds: parallelism, and sorting. I don't mind reviewing the aspects of it that touch on whether parallelism is being done right, but I would like to have some help on the sorting end of things. FWICT, Heikki's work on that end of things resulted in a material improvement to the patch; there is no reason to suppose that no problems in that area remain. I have committed sorting patches in the past, but I don't consider that I am an expert on it. If anybody who is would be willing to help with the review of this, I would find it a very welcome development. I do not propose the above as an exhaustive list of patches that have been pending for too long as a result of perhaps not having gotten the attention that they deserved, and I'm happy to have other people point out which patches they think fall into this category. They are merely some whose suffering has come to my attention. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, Mar 3, 2017 at 10:43 PM, Robert Haas <robertmhaas@gmail.com> wrote: > Parallel tuplesort (originally submitted to CommitFest 2016-09) > https://commitfest.postgresql.org/13/690/ > Heikki and I have both done a little work to move this forward, but it > needs a lot more attention than it has gotten. As I see it, this > patch touches on two worlds: parallelism, and sorting. I would like to remind anyone that is interested that I have maintained an extensive Wiki page for this project, right up until this week: https://wiki.postgresql.org/wiki/Parallel_External_Sort > I don't mind > reviewing the aspects of it that touch on whether parallelism is being > done right, but I would like to have some help on the sorting end of > things. Your covering those aspects seems like something that would make this an easier sell to another reviewer. Thanks! -- Peter Geoghegan
On Sat, Mar 4, 2017 at 3:43 PM, Robert Haas <robertmhaas@gmail.com> wrote: > Fix the optimization to skip WAL-logging on table created in the same > transaction (originally submitted to CommitFest 2016-03) > https://commitfest.postgresql.org/13/528/ > Michael perhaps-unwisely set the committer on this one to Heikki, > which led me and perhaps other committers to think he was going to > take care of it. But he may not have intended to do that; it's best to > let committers claim patches for themselves rather than assign them. > That having been said, I think it's bad when a known data-corrupting > bug goes unfixed for a year and a half FWIW, at the end of the thread Heikki has mentioned that he would move those patches forward to commit, so setting him as the owner looked quite adapted at this time. If it is an issue that a hacker sets the committer field in a CF entry and that only a committer should do it, I'd suggest to make that clear. Well if that's a problem I just won't do that anymore. > SCRAM Authentication (originally submitted to CommitFest 2015-09) > https://commitfest.postgresql.org/13/993/ > This patch has been evolving until very recently, and maybe still, so > it's maybe unfair to put it into the same category as the previous > two, but I don't think anybody is going to be very happy about waiting > another year for an alternative to MD5 authentication. Even though > there's not, to my knowledge, an effective preimage attack for MD5, > surely we want to have alternatives in case one is developed. That's > not going to be something we can back-patch. Heikki did quite a bit > of work to drive this forward, but seems to have had little time to > push that work forward lately. I don't know if there's another > committer who can pick this up. No idea. Let's see. > I initially thought I could help, but > the fact that the thread has ended up a discussion of Unicode > normalization has intimidated me a bit. The learning curve is steep, but once you understand what the string normalizations are made of there is not much more going on. -- Michael
On Sat, Mar 4, 2017 at 12:45 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > On Sat, Mar 4, 2017 at 3:43 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> Fix the optimization to skip WAL-logging on table created in the same >> transaction (originally submitted to CommitFest 2016-03) >> https://commitfest.postgresql.org/13/528/ >> Michael perhaps-unwisely set the committer on this one to Heikki, >> which led me and perhaps other committers to think he was going to >> take care of it. But he may not have intended to do that; it's best to >> let committers claim patches for themselves rather than assign them. >> That having been said, I think it's bad when a known data-corrupting >> bug goes unfixed for a year and a half > > FWIW, at the end of the thread Heikki has mentioned that he would move > those patches forward to commit, so setting him as the owner looked > quite adapted at this time. Ah, OK. So I'd say your action was justified, then, but in light of the amount of time that's gone by, I think we might need to find another vi^Holunteer. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company