Re: [HACKERS] Last gasp
On Thu, Apr 5, 2012 at 6:33 PM, Hannu Krosing 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
Re: [HACKERS] Last gasp
On Sat, Apr 7, 2012 at 5:20 PM, Tom Lane 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. -- Ro
Re: [HACKERS] Last gasp
Andrew Dunstan 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
On 7 April 2012 23:51, Tom Lane 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
On 04/07/2012 06:33 PM, Peter Geoghegan wrote: On 7 April 2012 22:20, Tom Lane 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
Peter Geoghegan writes: > On 7 April 2012 22:20, Tom Lane 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
On 7 April 2012 22:20, Tom Lane 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
On 7 April 2012 22:20, Tom Lane 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
Robert Haas 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
On Fri, Apr 6, 2012 at 3:22 AM, Greg Smith 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 abou
Re: [HACKERS] pgsql_fdw, FDW for PostgreSQL server
2012/4/7 Shigeru HANADA : > 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] Fix PL/Python metadata when there is no result
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] ECPG FETCH readahead
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] patch: bytea_agg
Peter Eisentraut 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
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
[HACKERS] Regarding GSoc Application
Hi All, I submitted a GSoc application yesterday. Please review it and let me know if anyone needs any clarifications. Atri
Re: [HACKERS] patch: bytea_agg
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
Re: [HACKERS] pg_upgrade improvements
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
