Re: Last Commitfest patches waiting review

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Last Commitfest patches waiting review
Дата
Msg-id 32023.1411827123@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Last Commitfest patches waiting review  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Ответы Re: Last Commitfest patches waiting review  (Andres Freund <andres@2ndquadrant.com>)
Re: Last Commitfest patches waiting review  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-hackers
Heikki Linnakangas <hlinnakangas@vmware.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Sloppy thinking about leakproof properties of opclass co-members
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Last Commitfest patches waiting review