Re: [HACKERS] pg_upgrade improvements

2012-04-07 Thread Peter Eisentraut
On ons, 2012-04-04 at 19:26 -0700, Harold Giménez wrote:
 It would also be nice if the invocation of pg_ctl didn't pipe its
 output to /dev/null. I'm sure it would contain information that would
 directly point at the root cause and could've saved some debugging and
 hand waving time.

This aspect has been reworked in 9.2devel.  Check it out to see if it
works better for you.


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] patch: bytea_agg

2012-04-07 Thread Peter Eisentraut
On ons, 2012-04-04 at 18:59 -0400, Tom Lane wrote:
 
  Why not call it string_agg?
 
  Here is a patch to do the renaming.  As it stands, it fails the
  opr_sanity regression test, because that complains that there are now
  two aggregate functions string_agg with different number of arguments.
  It seems to me that that test should really only complain if the common
  argument types of the two aggregates are the same, correct?
 
 Uh, no.  That test is there for good and sufficient reasons, as per its
 comment:
 
 -- Check that there are not aggregates with the same name and different
 -- numbers of arguments.  While not technically wrong, we have a project 
 policy
 -- to avoid this because it opens the door for confusion in connection with
 -- ORDER BY: novices frequently put the ORDER BY in the wrong place.
 -- See the fate of the single-argument form of string_agg() for history.
 
 The renaming you propose would only be acceptable to those who have
 forgotten that history.  I haven't.

I had reviewed that thread very carefully, but I'm not sure it applies.
The issue was that we don't want aggregates with optional second
argument, because novices could confuse

agg(a, b ORDER BY c)

with

agg(a ORDER BY b, c)  -- wrong

without the error being flagged.

But that doesn't apply if the first argument has different types.
Erroneously calling agg(textdatum ORDER BY textdatum, sthelse) will not
result in a call to agg(bytea).  (Unless the textdatum is really an
unknown literal, but that would be silly.)

Nevertheless, the problem would now be that adding string_agg(bytea)
would effectively forbid adding string_agg(bytea, delim) in the future.
So making a two-argument string_agg(bytea, bytea) now seems like the
best solution anyway.  (This applies independently of the function
renaming, actually.)



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] Regarding GSoc Application

2012-04-07 Thread Atri Sharma
Hi All,

 

I submitted a GSoc application yesterday. Please review it and let me know
if anyone needs any clarifications.

 

Atri



Re: [HACKERS] ECPG FETCH readahead

2012-04-07 Thread Michael Meskes
On Fri, Mar 30, 2012 at 12:48:07AM +0200, Boszormenyi Zoltan wrote:
 Attached is the new core feature patch. Summary of changes:
 ...
 I also refreshed the second patch that drives all cursors with the new
 ...

I'm slightly confused here. It seems Zoltan added a second patch *after* Noah
marked this patch as ready for committer. That second patch seems to apply
cleanly after the first one got applied. Now, which one was reviewed and is
considered ready for commit? The first one? Or both? 

Michael

-- 
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
Jabber: michael.meskes at googlemail dot com
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] patch: bytea_agg

2012-04-07 Thread Tom Lane
Peter Eisentraut pete...@gmx.net writes:
 On ons, 2012-04-04 at 18:59 -0400, Tom Lane wrote:
 Uh, no.  That test is there for good and sufficient reasons, as per its
 comment:

 I had reviewed that thread very carefully, but I'm not sure it applies.
 The issue was that we don't want aggregates with optional second
 argument, because novices could confuse

 agg(a, b ORDER BY c)

 with

 agg(a ORDER BY b, c)  -- wrong

 without the error being flagged.

 But that doesn't apply if the first argument has different types.
 Erroneously calling agg(textdatum ORDER BY textdatum, sthelse) will not
 result in a call to agg(bytea).

The point of the policy is to be sure that we will throw a specific
error message with a suitable hint when a malformed call is made.
If there are alternative aggregates in the catalogs that have the
potential to capture such a call, then we risk the wrong thing
happening.  It appears that the lack of any implicit cast from bytea to
text would prevent that today, but I still think this proposal boxes
us in to an unreasonable degree compared to the benefit.  For example,
this would greatly restrict our ability to throw ambiguous aggregate
messages.

 Nevertheless, the problem would now be that adding string_agg(bytea)
 would effectively forbid adding string_agg(bytea, delim) in the future.
 So making a two-argument string_agg(bytea, bytea) now seems like the
 best solution anyway.  (This applies independently of the function
 renaming, actually.)

Hm.  So are you now suggesting we should get rid of one-argument
bytea_agg and replace it with two-argument string_agg(bytea,bytea)?
I could support that, since we've not released bytea_agg yet.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] ECPG FETCH readahead

2012-04-07 Thread Noah Misch
On Sat, Apr 07, 2012 at 01:20:08PM +0200, Michael Meskes wrote:
 On Fri, Mar 30, 2012 at 12:48:07AM +0200, Boszormenyi Zoltan wrote:
  Attached is the new core feature patch. Summary of changes:
  ...
  I also refreshed the second patch that drives all cursors with the new
  ...
 
 I'm slightly confused here. It seems Zoltan added a second patch *after* Noah
 marked this patch as ready for committer. That second patch seems to apply
 cleanly after the first one got applied. Now, which one was reviewed and is
 considered ready for commit? The first one? Or both? 

Both.  The second patch appeared after my first review, based on a comment in
that review.  I looked at it during my re-review before marking the overall
project Ready for Committer.

I do call your attention to a question I raised in my second review: if a
program contains DECLARE foo READAHEAD 5 CURSOR FOR ... and the user runs
the program with ECPGFETCHSZ=10 in the environment, should that cursor use a
readahead window of 5 or of 10?  Original commentary:
http://archives.postgresql.org/message-id/20120329004323.ga17...@tornado.leadboat.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Fix PL/Python metadata when there is no result

2012-04-07 Thread Peter Eisentraut
On tor, 2012-04-05 at 19:49 +0200, Jean-Baptiste Quenot wrote:
 I consider that this is an error to request metadata when the query does
 not return some.  For example: UPDATE mytable SET value = 1 does not
 return column metadata, so user is not supposed to col coltypes().  That's
 why I propose to return an error.  coltypes() is supposed to return a
 sequence, not None.  Checking for None is a bad coding practise IMO,
 especially when dealing with lists. 

What would you suggest instead then?


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] pgsql_fdw, FDW for PostgreSQL server

2012-04-07 Thread Thom Brown
2012/4/7 Shigeru HANADA shigeru.han...@gmail.com:
 I've updated pgsql_fdw so that it can collect statistics from foreign
 data with new FDW API.

I notice that if you restart the remote server, the connection is
broken, but the client doesn't notice this until it goes to fire off
another command.  Should there be an option to automatically
re-establish the connection upon noticing the connection has dropped,
and issue a NOTICE that it had done so?

Also I'm not particularly keen on the message provided to the user in
this event:

ERROR:  could not execute EXPLAIN for cost estimation
DETAIL:  FATAL:  terminating connection due to administrator command
FATAL:  terminating connection due to administrator command

There's no explanation what the administrator command was, and I
suspect this is really just a I don't know what's happened here
condition.  I don't think we should reach that point.

-- 
Thom

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Last gasp

2012-04-07 Thread Robert Haas
On Fri, Apr 6, 2012 at 3:22 AM, Greg Smith g...@2ndquadrant.com wrote:
 On 04/05/2012 05:03 PM, Daniel Farina wrote:
 To get to the point, I wonder if it makes sense for someone who has a
 better sense a-priori what they're looking for in a committable patch
 (i.e. a committer, or someone with a telepathic link to one or more)
 to delegate specific pieces of patches for thorough review, sketching
 some thoughts about pitfalls or hazards to look for.  Think of it as a
 patch checklist that is informed by the experience of a committer
 skimming its contents.

 It's tricky to add this sort of idea into the current patch workflow in all
 cases.  A decent percentage of submissions bounce off a reviewer who doesn't
 commit, such that no committer spends time on them yet they still move
 forward.  Any idea that tries to involve committers earlier in the process
 risks using more of their time on things that ultimately are never going to
 pass toward commit anyway.  That is after all where this whole process
 started at, before CFs, and we know that didn't scale well.

 We already have a loose bar in this exact area, one that suggests larger
 patches should first appear earlier in the development cycle.  That happened
 in this case, with a first submission in mid November, but it wasn't enough
 to make things go smoothly.

 When I trace back how that played out, I think the gap in this case came
 from not being sure who was going to commit the result at the end.  If it's
 early January, and the community knows there's a large feature approaching
 because it's been around for over a month already, we better be asking who
 is going to commit it eventually already.  Many patch submitters agonize
 over which committer is going to grill me most?, and the bigger the patch
 the more that impacts them.

 Nailing that down and putting together the sort of early committer checklist
 you're describing strikes me as something that might happen in the first
 week of a CF, before there are normally a large pile of Ready for
 Committer things around.  Raising these question--who is interesting in
 committing big things and where they consider the bar to be--is something
 submitters who have a stake in seeing their patches go on might do.

 It's better if people who are already working hard on features don't feel
 like they need to wander around begging for someone to pay attention to them
 though.  Ideally it would be the sort of thing a proper CF manager would
 highlight for them.  Unfortunately we often don't quite have one of those,
 instead just having people who sometimes make a bunch of noise at the
 beginning of a CF and then go AWOL. (cough)  No one is happy about that, and
 it's something that clearly needs to be solved better too.

I think this basically just boils down to too many patches and not
enough people.  I was interested in Command Triggers from the
beginning of this CommitFest, and I would have liked to pick it up
sooner, but there were a LOT of patches to work on for this
CommitFest.  The first three CommitFests of this cycle each had
between 52 and 60 patches, while this one had 106 which included
several very complex and invasive patches, command triggers among
them.  So there was just a lot more to do, and a number of the people
who submitted all of those patches didn't do a whole lot to help
review them, sometimes because they were still furiously rewriting
their submissions.  It's not surprising that more patches + fewer
reviewers = each patch getting less attention, or getting it later.

Even before this CommitFest, it's felt to me like this hasn't been a
great cycle for reviewing.  I think we have generally had fewer people
doing reviews than we did during the 9.0 and 9.1 cycles.  I think we
had a lot of momentum with the CommitFest process when it was new, but
three years on I think there's been some ebbing of the relative
enthusiastic volunteerism that got off the ground.  I don't have a
very good idea what to do about that, but I think it bears some
thought.  On a related note, letting CommitFests go on for three
months because there's insufficient reviewer activity to get them done
in one or two is, in my opinion, not much of a solution.  If there's
even less reviewer activity next time, are we going to let it go on
for four months?  Six months?  Twelve months?  At some point, it boils
down to we're just going to stop accepting patches for an indefinite
period of time.  Yuck.

I also think we need to be generally more open to negative feedback
than we are.  Most if not all people who give negative feedback are
not doing so because they wish to torpedo a given patch as because
they have legitimate concerns which, since we are a community of smart
and talented people here, are often well-founded.  I've been there
myself, and it's occasionally frustrating, but overall it leads to me
doing better work than I otherwise would, which is a hard outcome to
complain about when you get right down to it.  

Re: [HACKERS] Last gasp

2012-04-07 Thread Tom Lane
Robert Haas robertmh...@gmail.com writes:
 [ among other good points ]
 ... On a related note, letting CommitFests go on for three
 months because there's insufficient reviewer activity to get them done
 in one or two is, in my opinion, not much of a solution.  If there's
 even less reviewer activity next time, are we going to let it go on
 for four months?  Six months?  Twelve months?  At some point, it boils
 down to we're just going to stop accepting patches for an indefinite
 period of time.  Yuck.

Yeah, this is something I was thinking about yesterday.  In the first
couple of release cycles with the CommitFest process, we were willing to
let the last fest of a release cycle go on for as long as it takes,
or at least that was what I felt the policy to be.  This time we
eventually gave up and declared closure, but in hindsight we should
likely have done that a month earlier.  The fact of the matter is that
quite a few of the patches we were dealing with were *not* ready to
commit, or even close to that, at the start of the fest.  If it weren't
the last fest they would have gotten marked Returned With Feedback a
lot sooner.

I wonder whether we ought to have a preset schedule for last fests
just like the others.  I'd be willing to let them run, say, 2 months
instead of 1, but no deadline at all risks turning the whole affair
into a death march, which is no fun for anybody and threatens the
quality of the end result too.  There's too much temptation to commit
patches that are not really ready, just to get them out of the way.

In short, the idea of strongly calendar-driven releases looks more
and more attractive to me the more times we go through this process.
If your patch isn't ready on date X, then it's not getting into this
release; but there'll be another bus coming along before long.
Stretching out release cycles to get in those last few neat features
just increases the pressure for more of the same, because people don't
know how long it will be to the next release.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Last gasp

2012-04-07 Thread Thom Brown
On 7 April 2012 22:20, Tom Lane t...@sss.pgh.pa.us wrote:
 In short, the idea of strongly calendar-driven releases looks more
 and more attractive to me the more times we go through this process.
 If your patch isn't ready on date X, then it's not getting into this
 release; but there'll be another bus coming along before long.
 Stretching out release cycles to get in those last few neat features
 just increases the pressure for more of the same, because people don't
 know how long it will be to the next release.

I'd imagine that clear deadlines may provide the impetus necessary to
get patches in earlier, patches updated more promptly, enthuse
patch-writers to lobby for review, and overall make commitfests a bit
more manageable.

And I'd be *strongly* against any relaxing of the current review
process, and I don't think it's realistic for PostgreSQL.  I want cool
new features to get in as much as anyone, but if there are genuine
concerns, those features really aren't yet ready for prime time.  A
perfect example of this is command triggers (now known as event
triggers), where the feature that would have got committed wouldn't
have been as flexible, elegant or sane as the feature that probably
will get committed in 9.3, and I think there's plenty of outstanding
questions around it too.  There wouldn't be enough room for movement
if the design needed anything beyond tweaking, and being painted into
a corner would be depressing for all concerned.

-- 
Thom

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Last gasp

2012-04-07 Thread Peter Geoghegan
On 7 April 2012 22:20, Tom Lane t...@sss.pgh.pa.us wrote:
 In short, the idea of strongly calendar-driven releases looks more
 and more attractive to me the more times we go through this process.
 If your patch isn't ready on date X, then it's not getting into this
 release; but there'll be another bus coming along before long.
 Stretching out release cycles to get in those last few neat features
 just increases the pressure for more of the same, because people don't
 know how long it will be to the next release.

I hope that that policy will not be applied without some degree of
discrimination.

I understand that this is an open-source project, and on a certain
level it has to be that simple, because we don't have any other way of
making contributors more conscientious about scheduling
considerations, except of course for giving them a nudge.  That said,
all features are not equal, and clearly some are of particular
strategic importance to the project, and as such may be worth holding
up the release for, subject to certain parameters. Which of these
features are worth holding the release up for is highly dependent on
their state at the time of the final commitfest deadline. Which
features are of strategic importance is of course a matter of opinion,
but that's the kind of thing that we have a steering committee for,
right?

Perhaps a good compromise would be to formalise the process through
which patches get a second chances in the final commitfest. I don't
think that it will prove workable to have a final deadline that is
adhered to blindly.

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Last gasp

2012-04-07 Thread Tom Lane
Peter Geoghegan pe...@2ndquadrant.com writes:
 On 7 April 2012 22:20, Tom Lane t...@sss.pgh.pa.us wrote:
 In short, the idea of strongly calendar-driven releases looks more
 and more attractive to me the more times we go through this process.
 If your patch isn't ready on date X, then it's not getting into this
 release; but there'll be another bus coming along before long.

 I hope that that policy will not be applied without some degree of
 discrimination.

Sure, but ...

 I understand that this is an open-source project, and on a certain
 level it has to be that simple, because we don't have any other way of
 making contributors more conscientious about scheduling
 considerations, except of course for giving them a nudge.  That said,
 all features are not equal, and clearly some are of particular
 strategic importance to the project, and as such may be worth holding
 up the release for, subject to certain parameters. Which of these
 features are worth holding the release up for is highly dependent on
 their state at the time of the final commitfest deadline. Which
 features are of strategic importance is of course a matter of opinion,
 but that's the kind of thing that we have a steering committee for,
 right?

... we have tried that approach repeatedly in the past, and it's
basically never worked.  There were multiple release cycles where we
held up a release to get some super important feature in, and
invariably either the release was *way* later than anybody expected,
or we gave up waiting and released without it.  Meanwhile, development
of anything else ground to a standstill.  Check the archives and you'll
see this theme played out a number of times.  We've more or less learned
not to do that, but we've never taken the plunge of setting hard feature
freeze deadlines well in advance.  I'm thinking maybe we should.

As for the steering committee, core tries hard not to make technical
decisions for the project; it's better to let those emerge by consensus.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Last gasp

2012-04-07 Thread Andrew Dunstan



On 04/07/2012 06:33 PM, Peter Geoghegan wrote:

On 7 April 2012 22:20, Tom Lanet...@sss.pgh.pa.us  wrote:

In short, the idea of strongly calendar-driven releases looks more
and more attractive to me the more times we go through this process.
If your patch isn't ready on date X, then it's not getting into this
release; but there'll be another bus coming along before long.
Stretching out release cycles to get in those last few neat features
just increases the pressure for more of the same, because people don't
know how long it will be to the next release.

I hope that that policy will not be applied without some degree of
discrimination.


If we are to have time based releases, then I assume it won't, it will 
be pretty much a hard and fast rule.


I admit I haven't been a fan in the past, but I can see advantages, not 
least being predictability of release times. It would be nice to be able 
to say In June when asked when the next release will be, as I often am.


cheers

andrew


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Last gasp

2012-04-07 Thread Peter Geoghegan
On 7 April 2012 23:51, Tom Lane t...@sss.pgh.pa.us wrote:
 As for the steering committee, core tries hard not to make technical
 decisions for the project; it's better to let those emerge by consensus.

I don't really consider this to be an engineering problem, which is
precisely why I bring up the role of core here. Holding up a release
for a feature has costs (the feature is delayed, which in some way
hurts us, as our users don't have a new release for that much longer,
etc) and benefits (when the release is available, Postgres is that
much better one release sooner). Naturally, the maturity of the
existing code, as judged by the community, would be heavily weighed in
this process, but the wider importance of the feature, and how much of
an advantage having it earlier provides, would also be weighed.

Open source products (as distinct from projects) often have this sort
of cost-benefit analysis made by individuals who are somewhat removed
from the engineering decisions themselves. While I'm certainly not
advocating that we switch to that model - in particular, I am not
advocating anything less than full transparency - surely there is
something to be said for some aspects of it, mostly to break the sorts
of deadlocks that can sometimes occur.

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Last gasp

2012-04-07 Thread Tom Lane
Andrew Dunstan and...@dunslane.net writes:
 On 04/07/2012 06:33 PM, Peter Geoghegan wrote:
 I hope that that policy will not be applied without some degree of
 discrimination.

 If we are to have time based releases, then I assume it won't, it will 
 be pretty much a hard and fast rule.

 I admit I haven't been a fan in the past, but I can see advantages, not 
 least being predictability of release times. It would be nice to be able 
 to say In June when asked when the next release will be, as I often am.

Just to be clear ... I don't believe that we can have hard-and-fast
*release* dates.  I am suggesting that it might be a good idea to have
a hard deadline for committing new features.  But beta test phase will
take however long it takes.  I don't think shaking out bugs is a
predictable process.

regards, tom lane

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] Last gasp

2012-04-07 Thread Robert Haas
On Sat, Apr 7, 2012 at 5:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
 I wonder whether we ought to have a preset schedule for last fests
 just like the others.

It's always been my feeling that we should have that.

 There's too much temptation to commit
 patches that are not really ready, just to get them out of the way.

This is something I'm really concerned about.  During both the 9.0 and
9.1 cycle, we did some of this, and ended up paying for it with months
of bug fixing - not of *everything* that was committed late in the
cycle, but of certain particular patches.  We ended up producing
quality releases anyway, but I think if we had pushed it much farther
than we did, that might not have happened, or it might have pushed the
release out quite a bit more.  I think we have to be careful not to
set the bar for big patches unreasonably high (or big features will
never get done) but I honestly do not believe we have that problem.
Which recent release did not end up with its share of big features?
People like Jeff Davis, KaiGai Kohei, and myself who submitted their
major work (or the preparatory refactorings) relatively early in this
release cycle had no real trouble getting commits.  It is the patches
that showed up in November, December, and January that ended up on the
skids.  On the flip side, we do have a problem with looming deadlines
causing a lot of pressure to push stuff in that isn't ready.  There
were a number of times this CommitFest when someone said, hey, I'm
going to push X, and I said... uh, let me drop what I'm doing and take
a look at that, because it doesn't sound ready to me.  Some of those
commits happened anyway and others didn't, but all of them seemed like
the outgrowth of time pressure rather than real certainty that we were
in a good place.

 In short, the idea of strongly calendar-driven releases looks more
 and more attractive to me the more times we go through this process.
 If your patch isn't ready on date X, then it's not getting into this
 release; but there'll be another bus coming along before long.
 Stretching out release cycles to get in those last few neat features
 just increases the pressure for more of the same, because people don't
 know how long it will be to the next release.

Well, the other side of the coin is that the next release will
probably be in a little over a year, and that's longer than people
want to wait even if it's a known quantity.  But I'm not sure there's
much we can do about that, unless we want to cut the cycle from four
CommitFests to three, or something like that.  I think I'd actually be
in favor of that, because it seems to me that nearly every feature
anyone wants can be gotten done in two CommitFests.  There are a few
exceptions, like sepgsql and SSI and (now) command triggers, but it's
not like we have tons of developers who start in CF1 and just barely
get their work in by CF4.  What happens more often is that the early
CommitFests are kind of dead, and then there's a huge flood of stuff
for the last one because, hey, there's gonna be a release soon, I
should do something for it!  We might find that if we did 3-CF cycles
rather than 4-CF cycles we got the same number of features about two
months sooner.

Or we might not find that.  But it's not clear that cutting off a
CommitFest would have hurt this release much, or that adding another
one would have helped much.  Adding one *now* might help, because some
of the big patches that were submitted at the beginning might then
make it in, but if we'd had all of this extra time budgeted in from
the beginning (e.g. last CommitFest planned for March 1st instead of
January 15th) I think a decent number of the submissions would have
just come that much later.  Love may be the strongest human emotion,
but procrastination has got to be in the top five.

The only thing I can really see helping us to avoid the crush of last
minute patches is to have strong, clear, and vigorously enforced rules
about rejecting major features that are not submitted early enough, or
that are not in good enough shape when submitted.  As you said in your
reply to Peter, making exceptions because features are important is
not helpful.  My features are important, too, but I get them done
early.  Granted, not everyone has as much work time to work on
community PostgreSQL as I do, but it's simply impossible to believe
that everyone's schedule suddenly clears up in the first half of
January every year.  If there's something magic about that half-month
then we've chosen a poor timing for our final CommitFest, but my
theory is that we'd have the same problem no matter when we did it.
If we start aggressively booting things early, then we don't have to
have arguments at the end.  But then again, we'd have to have the
arguments earlier.  I continue to think that there's no real solution
here if people are bound on claiming that the feature they
particularly like ought to be excepted from the deadlines that apply
to everyone else.


Re: [HACKERS] Last gasp

2012-04-07 Thread Robert Haas
On Thu, Apr 5, 2012 at 6:33 PM, Hannu Krosing ha...@krosing.net wrote:
 I would really like the controversial parts of the recent feature creep
 to get un-creeped :)

 At least until 9.3 .

This argument would hold more water if I hadn't been encouraging
Dimitri to pick a less aggressive target for this feature in just
about every review of the feature that I did.  Yes, I want a general
syntax that will accommodate not only our immediate goals, but also
other things that we will certainly want to do in the future.  I think
anything else would be very short-sighted.  That having been said, I
have repeatedly encouraged whittling this feature down to a smaller
initial subset, with only partial success.  I still think that's one
of the things to happen for next CommitFest.  Introducing both a
general framework for command/event triggers and a rather complex and
invasive initial firing point that requires surgery on the guts of
every DDL command in the system basically means we've got two major
features in one patch.  That's a lot to review, and twice as many ways
to fail.

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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers