Re: Last Commitfest patches waiting review

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, Peter Geoghegan <pg(at)heroku(dot)com>, Kevin Grittner <kgrittn(at)ymail(dot)com>, "Brightwell, Adam" <adam(dot)brightwell(at)crunchydatasolutions(dot)com>, Emre Hasegeli <emre(at)hasegeli(dot)com>, Rukh Meski <rukh(dot)meski(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Last Commitfest patches waiting review
Date: 2014-09-27 14:12:03
Message-ID: 32023.1411827123@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
> [ unreviewed patches ]

> Grouping Sets

> There has been a lot of discussion, but no decisions. See
> http://www.postgresql.org/message-id/87vbodhtvb.fsf@news-spur.riddles.org.uk.

> Would a committer be interested to take responsibility of this? If not,
> this will just linger indefinitely.

I should and will take this, but not in this commitfest: I've been just
horribly busy lately with both work and personal issues. If we can punt
it to the next fest, I will promise to work on it then.

> INNER JOIN removals

> The latest patch is significantly different from what was originally
> submitted for the commitfest, so I wouldn't feel bad just bumping this
> to the next one. I'll do that unless someone picks this up soon.
> Tom: I know you're busy with the more urgent jsonb patch.. Do you think
> you would find the time to review this anytime soon? Anyone else?

Same deal here.

> Selectivity estimation for inet operators

> I think there's a bug in the estimation of semi-joins, see
> http://www.postgresql.org/message-id/5423DC8D.3080206@vmware.com. But I
> think we could split this patch into two, and commit the non-join
> selectivity estimator first, as that seems OK. If no-one else steps up
> to the plate, I can do that..

And I'd like to look this one over too ...

> Escaping from blocked send() by pg_terminate_backend().

> I've had a look, but I'd like to have a second opinion on this.

I concur with your opinion that this is scary as heck. We need multiple
pairs of eyeballs if we're going to do anything in this area. In the long
run though, I think pushing functionality into signal handlers is exactly
backwards; we ought to be trying to go the other way.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-09-27 15:17:03 Re: Last Commitfest patches waiting review
Previous Message Tom Lane 2014-09-27 13:52:57 Re: Sloppy thinking about leakproof properties of opclass co-members