On Thu, Mar 2, 2017 at 6:58 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers