Re: 2017-03 Commitfest In Progress

On Thu, Mar 2, 2017 at 6:58 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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