Re: Is it time for triage on the open patches? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Is it time for triage on the open patches?
Date
Msg-id CA+TgmoaTkrO-Mpq7x=zeq_MBMeCTTQe9Nt=R3B=Ec2pokOFbDA@mail.gmail.com
Whole thread Raw
In response to Is it time for triage on the open patches?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Is it time for triage on the open patches?  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Is it time for triage on the open patches?  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
List pgsql-hackers
On Fri, Mar 9, 2012 at 2:47 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> This is a fair position, but I think it's a bit unfair to be applying
> such pressure to just the command-triggers patch and not all the other
> open issues.  Hence, $SUBJECT: is it time to start forcing this
> commitfest to a conclusion, and if so what kind of schedule are we
> trying to set?

Just to be clear, it wasn't my intention to hold command triggers
specifically to a different standard - but I do differentiate between
small patches and big patches.  Small patches that someone can get
committed with an hour's worth of review can be treated a little more
leniently than large patches that may take many cycles of review
adding up to days of effort, and I believe command triggers to be one
such patch.

> Personally, the open patches that I'm excited about getting into the
> tree (or at least trying hard to) are:
>        * NULLs support in SP-GiST
>        * Caching constant stable expressions per execution
> and not that much else.  (I'm also interested in the pgsql_fdw patch
> but I'm afraid that getting it to committable shape in the next week
> or two may be unrealistic.)  Probably other people have their own,
> different shortlists.

I'd like to get the two sepgsql patches done if possible.  I'm going
to commit the rest of the DROP patch shortly, and the GUC for client
label I will review and commit if it seems like it's in good shape.  I
would *like* to see Heikki's XLogInsert scaling patch committed, but
it seems like it's still too buggy for that, and I'm not sure how long
we should wait for it to get fixed; I also don't have plans to work on
it personally.  It's hard to pick favorites among the rest; there are
a number of things I'd like to work on, but if it's just me working on
them it's going to take longer than I want to wait for them to get
done.  There's been very little patch review going on, with a couple
of notable exceptions like Thom and Noah, and not a lot of new patch
versions from patch authors either, again with a few exceptions, like
Dimitri.  So it's not terribly surprising that progress is very slow.
I'm not sure what to do about that, either: it doesn't seem very fair
to start booting patches things that are in relatively good shape, but
on the other hand I'm not willing to single-handedly (or even with
both hands) take on the task of reviewing everything that nobody else
is paying attention to.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: xlog location arithmetic
Next
From: Yeb Havinga
Date:
Subject: Re: [v9.2] Add GUC sepgsql.client_label