Re: [HACKERS] Patch queue - wiki
Bruce Momjian wrote: That private email list has grown into something official because I am more thorough about it than most. If the community wants a more collaborative tool, they can create one or ask for additions to my web pages. If I need to take my pages offline to help, fine. If the new system is 10x harder than I what I do now, I will probably just keep doing what I am doing and just not make it visible. I can put some work into using the collaborative tool, but as I said before, we are going to need another 9x of effort. Personally I don't think either the March or May wiki pages are accurate enough, so that isn't a good sign. To me, what this means is that you're the perfect person to be helping making the wiki pages more accurate to cover all items that need attention. The fact that you seem to be fighting them (the pages), in spite of the fact that everyone else has started using them, seems a bit worrying to me. I don't know how to measure how much harder using the wiki page is on terms of the effort it takes you to update your pgpatches page -- so I don't know about 10x, 9x or how many X's I have already used up. But while I certainly spent a fair amount of work to create the initial version, the fact that they're up and running now means the work needed to keep them up to date is not tremendous. FWIW I've been asking patch submitters (privately) to add the patches they submit to the May commitfest pages, and they've mostly done it right away. If you click the history link on the May page you can see changes from Pavel Stehule, Teodor, Andrew Dunstan, Greg Start and Tom -- so we already have a reasonably complete overview of what we need to do on the next commitfest. I don't expect this to be a one-time affair. -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- 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 queue - wiki
Alvaro Herrera [EMAIL PROTECTED] writes: FWIW I've been asking patch submitters (privately) to add the patches they submit to the May commitfest pages, and they've mostly done it right away. If you click the history link on the May page you can see changes from Pavel Stehule, Teodor, Andrew Dunstan, Greg Start and Tom -- so we already have a reasonably complete overview of what we need to do on the next commitfest. I don't expect this to be a one-time affair. I think asking submitters to add their patches is a good idea and in fact Heikki's suggestion of having the wiki be primarily driven by submitters is a good idea. It gives people a central place to go back and check and find all the collected reviews and CVS status of their work and keeps us honest. I would like to suggest a few attributes we want for each patch: 1) Patch maturity (whether it was proposed as a design, WIP, or submission for committing). 2) Reviewers interested in working on the patch. I think it would help organize ourselves and make sure all the patches get covered. Also, it would help get people involved who are otherwise overtaken by more senior postgres hackers. Those hackers would probably focus on patches that were beyond the ability of more junior hackers and were otherwise getting ignored. 3) Committers working on integrating the code. No point in risking duplication. My first instinct is to convert it to a table. But perhaps we could just stick these attributes in the current format as sublist items under each major bullet point. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- 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 queue - wiki
Gregory Stark wrote: I would like to suggest a few attributes we want for each patch: [...] My first instinct is to convert it to a table. But perhaps we could just stick these attributes in the current format as sublist items under each major bullet point. I agree -- having these attributes on sight would be good. OTOH it wouldn't be good if having them means the wiki is much harder to edit, which makes me think that a table is not a good idea. Keeping the whole thing easy to edit is important to keep overhead low. Perhaps we should offer an empty template at the top of the page so that when a submitter wants to add a new patch, he puts the empty fields there so that a reviewer/commiter needs only complete them. For maturity I think we should have design, WIP, ready for final review (as in: the submitter thinks this is ready to commit), committed. Having a status: committed means we no longer need to move patches from one section to another. (OTOH having a separate section for committed patches is good because you can see at a glance how the commitfest is progressing, so maybe this is not such a hot idea.) -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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 queue - wiki
Alvaro Herrera wrote: Personally I don't think either the March or May wiki pages are accurate enough, so that isn't a good sign. To me, what this means is that you're the perfect person to be helping making the wiki pages more accurate to cover all items that need attention. The fact that you seem to be fighting them (the pages), in spite of the fact that everyone else has started using them, seems a bit worrying to me. I have offered to remove my web site pages. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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 queue - wiki (was varadic patch)
On Thu, Apr 3, 2008 at 4:55 PM, Bruce Momjian [EMAIL PROTECTED] wrote: That seems like a *really* odd thing for one of the founders of the world's most advanced OSS DBMS project to say. It's all relational (which we do do pretty well) - we can add links to the wiki to threads in the archives, and anything posted from then on is self-maintaining (except when new threads are started - but even if each patch gets 5 threads that's not a huge chore). I see no reason to go manually copying all 2k emails to the wiki. Well, I am waiting for someone to show me how it is done because I can't figure out a way. Do it and I will gladly stop doing what I am doing. We must be talking at cross purposes because I really cannot believe you're asking me how to add a link to a wiki page :-o Just in case though, the most simple way is to just add the URL with square brackets surrounding it: [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00131.php] To use different link text just add it after the URL: [http://archives.postgresql.org/pgsql-hackers/2008-04/msg00131.php Patch queue - Wiki] To link to another wiki page, put the target page title in double square brackets [[Developer and Contributor Resources]] -- Dave Page EnterpriseDB UK: http://www.enterprisedb.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 queue - wiki (was varadic patch)
On Fri, 4 Apr 2008, Dave Page wrote: We must be talking at cross purposes because I really cannot believe you're asking me how to add a link to a wiki page :-o He wants to know how to automate turning an entire mbox file full of them into wiki markup, now how to do one at a time. Other people have been running such tools for Bruce but he doesn't have one he can become comfortable with running himself yet. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- 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 queue - wiki
Greg Smith [EMAIL PROTECTED] writes: On Fri, 4 Apr 2008, Dave Page wrote: We must be talking at cross purposes because I really cannot believe you're asking me how to add a link to a wiki page :-o He wants to know how to automate turning an entire mbox file full of them into wiki markup, now how to do one at a time. Other people have been running such tools for Bruce but he doesn't have one he can become comfortable with running himself yet. Well since we stuck with the mbox for the March commitfest there's no need to do a batch migration. We'll just start with a wiki page for the May commitfest. There are only a handful of lines to put in the May commitfest and I think Alvaro's already put them in. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- 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 queue - wiki
Gregory Stark wrote: Greg Smith [EMAIL PROTECTED] writes: He wants to know how to automate turning an entire mbox file full of them into wiki markup, now how to do one at a time. Other people have been running such tools for Bruce but he doesn't have one he can become comfortable with running himself yet. Well since we stuck with the mbox for the March commitfest there's no need to do a batch migration. We'll just start with a wiki page for the May commitfest. There are only a handful of lines to put in the May commitfest and I think Alvaro's already put them in. Yeah, the May commitfest page is already up. I have been requesting patch submitters to add their entries there. The problem we had with the 2 emails was that we didn't have any record of patches waiting for review -- a problem that we will hopefully have only once. I would expect our next release (this one) to not have such a long queue of things, because of the whole commitfest idea. I agree with what some are saying here: there's no automatic notification when we add, remove or change status of patches, or other issues. I did voice my opinion that I thought a wiki page was not a real tracker. Hopefully, in working with the wiki we will gather enough experience that we'll be able to decide _how_ we want our tracker to work -- if we decide we want to switch from the wiki at all. BTW, Greg Stark already dumped the patch queue into a wiki page some time ago: http://wiki.postgresql.org/wiki/CommitFest:Bruce Do you think that's more useful than the other commitfest layout? I don't. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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 queue - wiki
Alvaro Herrera wrote: BTW, Greg Stark already dumped the patch queue into a wiki page some time ago: http://wiki.postgresql.org/wiki/CommitFest:Bruce Do you think that's more useful than the other commitfest layout? I don't. No. The bottom line is that I used to do this tracking in my own mailboxes but people wanted to see what was outstanding so the web pages were created. Basically a Wiki takes 10x more time for me to modify something, so unless I get another 9 people to do the same amount of work I do on tracking, we are going to fall behind. I am not willing to increase the amount of time I already spend doing this. Perhaps distributed over the community there will be 9x more time spent on tracking, but I doubt it. I think ultimately we are going to have to remove the patches email list and require patch submitters to add their patches to a patch tracker. Then all patch discussion will happen on hackers and in the patch tracker. I will continue to gather TODO emails, but those are not time-sensitive and few people seem to want to work on that. Frankly, few people seem to want to apply patches either. :-) Even with two patch queue web sites, Tom is doing the bulk of the work. I kept some of the easy ones in the queue for a long time hoping people would at least take those, but no one did. I am doing them at this point because we want this commit fest to be over. Also frankly, I feel I am hearing, Oh, we want to help but we don't know what to do, and when you show people what to do, they don't help. Yes, I am disapointed. If someone can explain why I shouldn't feel disapointed, I would love to hear it. If you want I will take my web pages offline and the community can see how it does with tracking. I will keep my mbox current just in case. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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 queue - wiki
Bruce Momjian [EMAIL PROTECTED] writes: Basically a Wiki takes 10x more time for me to modify something, so unless I get another 9 people to do the same amount of work I do on tracking, we are going to fall behind. I am not willing to increase the amount of time I already spend doing this. Perhaps distributed over the community there will be 9x more time spent on tracking, but I doubt it. On a busy day we might get 5 patches submitted or updated. That's five lines of text to add or edit. The hard part is reading the email and figuring out what status the patch is in. Not coincidentally the lack of that info is also why your list isn't very helpful. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- 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 queue - wiki
Gregory Stark [EMAIL PROTECTED] writes: Bruce Momjian [EMAIL PROTECTED] writes: Basically a Wiki takes 10x more time for me to modify something, so unless I get another 9 people to do the same amount of work I do on tracking, we are going to fall behind. I am not willing to increase the amount of time I already spend doing this. Perhaps distributed over the community there will be 9x more time spent on tracking, but I doubt it. On a busy day we might get 5 patches submitted or updated. That's five lines of text to add or edit. I think what Bruce is really complaining about here is that he's got years worth of development in his current infrastructure, and so it only costs him a few seconds and keystrokes to push stuff into his existing patch queue; while there's no such shortcuts for the wiki. Which is a fair complaint, but it's hardly insoluble. The hard part is reading the email and figuring out what status the patch is in. Certainly. What we've got to do is make sure that after someone has made that decision, it doesn't cost them a couple of minutes of drudgery to look up the appropriate email-archives URL and push it into the wiki page (probably with a comment). I can't imagine that this is terribly difficult, but web page scripting isn't one of my strengths ... 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] Patch queue - wiki
Tom Lane wrote: Gregory Stark [EMAIL PROTECTED] writes: Bruce Momjian [EMAIL PROTECTED] writes: Basically a Wiki takes 10x more time for me to modify something, so unless I get another 9 people to do the same amount of work I do on tracking, we are going to fall behind. I am not willing to increase the amount of time I already spend doing this. Perhaps distributed over the community there will be 9x more time spent on tracking, but I doubt it. On a busy day we might get 5 patches submitted or updated. That's five lines of text to add or edit. I think what Bruce is really complaining about here is that he's got years worth of development in his current infrastructure, and so it only costs him a few seconds and keystrokes to push stuff into his existing patch queue; while there's no such shortcuts for the wiki. Which is a fair complaint, but it's hardly insoluble. My infrastructure really took no time to construct because it is just pushing email around. I don't care if I have to scrap it. Basically it is an outgrowth of something I already do, and that is read the email stream. My guess is that no matter what we set up I am going to want to track things others don't want to see so I am still going to have my private list of emails I want to address. That private email list has grown into something official because I am more thorough about it than most. If the community wants a more collaborative tool, they can create one or ask for additions to my web pages. If I need to take my pages offline to help, fine. If the new system is 10x harder than I what I do now, I will probably just keep doing what I am doing and just not make it visible. I can put some work into using the collaborative tool, but as I said before, we are going to need another 9x of effort. Personally I don't think either the March or May wiki pages are accurate enough, so that isn't a good sign. FYI, others can add to the patch queue now; the email address is at the top of each page. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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 queue - wiki
Tom Lane [EMAIL PROTECTED] writes: Gregory Stark [EMAIL PROTECTED] writes: The hard part is reading the email and figuring out what status the patch is in. Certainly. What we've got to do is make sure that after someone has made that decision, it doesn't cost them a couple of minutes of drudgery to look up the appropriate email-archives URL and push it into the wiki page (probably with a comment). I can't imagine that this is terribly difficult, but web page scripting isn't one of my strengths ... Hm, the way you describe this I fear we would get the list of every individual email on the topic. What I think we want is usually to add a link to an existing entry and update the status. That pretty much does require going to the page and finding the entry in question. It probably would be neat if the email footer thingy added a url to each email it distributed via the lists pointing to the permanent message-id-based url in the archives for that message. Then at least you would have that handy. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- 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 queue - wiki
Bruce Momjian [EMAIL PROTECTED] writes: I think ultimately we are going to have to remove the patches email list and require patch submitters to add their patches to a patch tracker. That's outright silly. The email list and archives are a critical part of what we do, because they provide a historical record. Nor is raising the bar for submitting patches a good idea. The patch queue is by definition transient --- nobody particularly cares about what its past state was, as shown by the fact that you've gotten along for years with an implementation that's incapable of recalling past state. (Now I do like the idea that a wiki-based patch queue would retain some history, but I'm not expecting that it'll archive every change indefinitely.) The right way to think about and design the patch queue is as a changing index into the archives. One of the things I seriously dislike about your current implementation is that it ignores the archives. You've whacked us around two or three times this month developing permanent and then really permanent URLs, but that whole thing is wrong from the get-go. You are not the keeper of the project's historical record. The patch queue should be trafficking in URLs that do point into the historical record. Frankly, few people seem to want to apply patches either. :-) Yeah, tell me about it :-( 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] Patch queue - wiki
Tom Lane wrote: The patch queue is by definition transient --- nobody particularly cares about what its past state was, as shown by the fact that you've gotten along for years with an implementation that's incapable of recalling past state. (Now I do like the idea that a wiki-based patch queue would retain some history, but I'm not expecting that it'll archive every change indefinitely.) The right way to think about and design the patch queue is as a changing index into the archives. One of the things I seriously dislike about your current implementation is that it ignores the archives. You've whacked us around two or three times this month developing permanent and then really permanent URLs, but that whole thing is wrong from the get-go. You are not the keeper of the project's historical record. The patch queue should be trafficking in URLs that do point into the historical record. Sure, it would be nice if an email link could jump right into the archives, but until we have a way to get to the archives via a message-id, I know of know way to automate that. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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 queue - wiki
On Fri, 04 Apr 2008 22:37:17 -0400 Tom Lane [EMAIL PROTECTED] wrote: Bruce Momjian [EMAIL PROTECTED] writes: I think ultimately we are going to have to remove the patches email list and require patch submitters to add their patches to a patch tracker. That's outright silly. The email list and archives are a critical part of what we do, because they provide a historical record. Nor is raising the bar for submitting patches a good idea. Command Prompt uses a tool that allows us to transform emails to tickets via Trac. It is not perfect but it works for us. It has two modes, autocreate and not. With autocreate every email that hits the list is automatically a ticket. Without autocreate you must put: @trac create into the message body for a ticket to be created. The flow works like this: email [EMAIL PROTECTED] email-tracman-trac-list Where the email is intercepted by tracman, which reads the email to see if it is already a ticket, if so the ticket within trac gets updated and then the email is released to the listserv. If the email is not a ticket (and autocreate is on), tracman intercepts the email, creates a ticket in trac, rewrites the subject of the email to have the ticket number and releases the ticket to the list serv. Further if you want to update a ticket via the web interface to trac you can and it will also correctly deal with list traffic. The following commands are supported: @trac create : creates a ticket @trac assign : takes a second argument which allows you to assign to a person @trac close : closes a ticket In the current infrastructure the missing things for CMDs workflow is: 1. Attachments if sent via email stay a part of the email, if they are attached via trac, they stay part of the ticket. So you can actually have two sources of attachments. 2. There is no merge capability. At some point we want to be able to say this: @trac merge 27 And the email getting intercepted would automatically merge into ticket 27. I am not saying we should use this for the project. I am not even saying it is a good tool for the project. I am saying that if some hackers want to play with the idea for a patch queue using it, I would be happy to provide resource to that. I would also be willing to provide resources to make reasonable modifications to tracman to allow it to work for our environment. The key to this is, with very little effort we would have: * Proper attachment capability (gets saved into postgresql) * A single source for communication about patches * If we add merge, we can even forward an email from hackers that is relevant and merge it into a patch (which is a ticket). * Always see what the latest patch is because the ticket will have a patch and timestamp associated with when the patch came in * Have a wiki that can associate explicitly with the tickets/patches And if we ever change to mercurial, svn or git, we can use Trac as the front end and not only have a wiki,tickets,patches but also source tree references including changesets etc... Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate -- 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 queue - wiki
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Saturday, April 05, 2008 03:37:08 +0100 Gregory Stark [EMAIL PROTECTED] wrote: It probably would be neat if the email footer thingy added a url to each email it distributed via the lists pointing to the permanent message-id-based url in the archives for that message. Then at least you would have that handy. Actually, I think it was Magnus that asked me about this (or similar) ... I can add either an X-header, or something in the body, that includes the Message-Id, as ppl desire it ... - -- Marc G. FournierHub.Org Hosting Solutions S.A. (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.8 (FreeBSD) iEYEARECAAYFAkf2+/8ACgkQ4QvfyHIvDvMd6ACeOLY0WZNmhxuGxlUO/p0yIzRz xVQAoOxeO4o8R6RHv5PJNODjRpIjMxHM =FJhs -END PGP SIGNATURE- -- 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 queue - wiki (was varadic patch)
On Thu, Apr 3, 2008 at 12:35 AM, Bruce Momjian [EMAIL PROTECTED] wrote: It is not clear to me how a wiki can be easily created for 2k emails and then maintained in a reasonable way, or how emails can be added to it easily. That seems like a *really* odd thing for one of the founders of the world's most advanced OSS DBMS project to say. It's all relational (which we do do pretty well) - we can add links to the wiki to threads in the archives, and anything posted from then on is self-maintaining (except when new threads are started - but even if each patch gets 5 threads that's not a huge chore). I see no reason to go manually copying all 2k emails to the wiki. -- Dave Page EnterpriseDB UK Ltd: http://www.enterprisedb.com PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk -- 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 queue - wiki (was varadic patch)
The one concern I have with the way the last commitfest went (and I say this as strictly an observer), there was no discussion on anything. Now, I know that discussion happened, but it happened somewhere, in some web-forum, in a community that seems to generally promote mailing lists as the preferred method of discussion. As an observer, who generally doesn't have much input code wise, but occasionally might have an observation as a user, *I* would love to see the commitfest patch-queue be something pretty simple, along the lines of a big list of: 1) item name, submission date, author 2a) item intention (maybe a see $MSGID) 2b) item (see $MSGID) 3) status summary (in discussion, applied, needs $improvements, rejected, see $MSGID Note I said item because it appears as if the consensus is that the commit-fest has to deal with more than just patches, but also proposals, and fork-in-the-road details. And no, I don't think it should included the 2K emails. It should can the $N items needing to be dealt with, and a list of pointers to messages (which generally lead to threads), with a simple status list/summary for each one (again with pointers to $MSGID where specific information might be needed). Basically, I would like to see the patch queue be more a summary/pointer of/to discussion, then some web forum where the discussion happens. And I would like the mailling lists be where the discussion of items in the patch queue happens. But all this is the opinion of an observing devellopper, not involved in any of the heavy-lifting, but as someone who would like to keep an eye on what patches are presented, and their strengths/deficiencies, so that when I present my first patch/proposal, hopefully I can avoid most of the pitfalls. But don't cater to me. Cater to Tom and Bruce, who are the ones who actually use whatever is in place. Since they are the ones doing the work, I have to accept (or ignore) whatever system they use. a. * Bruce Momjian [EMAIL PROTECTED] [080402 19:36]: It is not clear to me how a wiki can be easily created for 2k emails and then maintained in a reasonable way, or how emails can be added to it easily. There are several steps: o getting those 2k emails to start the commit fest o getting them into a wiki in a way that is fast/efficient o updating the wiki for changes efficiently Keep in mind the patch emails are pretty dynamic. As you get closer to the end of the commit fest, the wiki is easier because the list of open items becomes more stable. I am able to give others the ability to add, move, and delete emails in my patch queue, if desired. If people want to use the wiki, go ahead --- this would be one less job for me to do. -- Aidan Van Dyk Create like a god, [EMAIL PROTECTED] command like a king, http://www.highrise.ca/ work like a slave. signature.asc Description: Digital signature
Re: [HACKERS] Patch queue - wiki (was varadic patch)
Aidan Van Dyk [EMAIL PROTECTED] writes: The one concern I have with the way the last commitfest went (and I say this as strictly an observer), there was no discussion on anything. Umm ... in the first place, the fest isn't over yet. In the second place, the reason you haven't seen much discussion is that we've been working primarily on the stuff that could be committed without much discussion. That underbrush has mostly been cleared away at this point, and we're starting to get down to the stuff that actually will need extended discussion. That should definitely happen on this list. The remaining open issues are listed here: http://momjian.us/cgi-bin/pgpatches Feel free to start talking about any of them ... 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] Patch queue - wiki (was varadic patch)
Dave Page wrote: On Thu, Apr 3, 2008 at 12:35 AM, Bruce Momjian [EMAIL PROTECTED] wrote: It is not clear to me how a wiki can be easily created for 2k emails and then maintained in a reasonable way, or how emails can be added to it easily. That seems like a *really* odd thing for one of the founders of the world's most advanced OSS DBMS project to say. It's all relational (which we do do pretty well) - we can add links to the wiki to threads in the archives, and anything posted from then on is self-maintaining (except when new threads are started - but even if each patch gets 5 threads that's not a huge chore). I see no reason to go manually copying all 2k emails to the wiki. Well, I am waiting for someone to show me how it is done because I can't figure out a way. Do it and I will gladly stop doing what I am doing. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Patch queue - wiki (was varadic patch)
On Wed, 2 Apr 2008, Bruce Momjian wrote: The new permanent ones are permanent against mailbox movement, and in fact the comments and thread merging also travels with the email. The someone replied to your comment links in e-messages I've been getting the last few days have all been working, which is a first. The configuration you're running right now I'd consider the first candidate to be a stable version, so thumbs up from me for reaching that point. It's clear to me only now that you can think of the patch queue as being a list with this structure: 1) Patch name (defaults to the subject of the first message) 2) List of messages related to that patch 3) List of comments 4) Status 5) Assigned reviewers Bruce's toolchain converts an mbox of messages to generate the first two, then has a web interface to allow adding the third. Right now the message list is internally consistant but not useful in the long term (doesn't have links to the archives, just this temporary page). Until the search for message ID feature is added to the archives I don't know that this situation can be improved. Those hacking on tools to convert Bruce's currently preferred working form (that revolves around mbox files) into something else that's web oriented are stuck with considering how all the above information is going to be handled before everybody will be satisfied. I can see how a script that converts the current pages into wiki markup, with placeholders where someone can manually update the comments to summarize those on the page, would be helpful. That basically creates an easier to read Queue summary like Stephan was doing for 8.3--that included items 1,4,5 from the above. But that's a one-way operation that doesn't really help with the commenting situation, and it's inevitably going to lag behind the mailbox-centered queue unless it's made fully automatic. I can't think of anything better that doesn't require building some sort of database that holds all this information and drives page generation. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD -- 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 queue - wiki (was varadic patch)
Greg Smith [EMAIL PROTECTED] writes: Those hacking on tools to convert Bruce's currently preferred working form (that revolves around mbox files) into something else that's web oriented are stuck with considering how all the above information is going to be handled before everybody will be satisfied. I can see how a script that converts the current pages into wiki markup, with placeholders where someone can manually update the comments to summarize those on the page, would be helpful. That basically creates an easier to read Queue summary like Stephan was doing for 8.3--that included items 1,4,5 from the above. But that's a one-way operation that doesn't really help with the commenting situation, and it's inevitably going to lag behind the mailbox-centered queue unless it's made fully automatic. I can't think of anything better that doesn't require building some sort of database that holds all this information and drives page generation. This seems to be ignoring the possibility of those involved with the patch queue simply manually editing the wiki page. For the past couple of weeks I've been dealing with both Bruce's queue and the one at http://wiki.postgresql.org/wiki/CommitFest:March and frankly I find the latter a *whole* lot more satisfactory, despite the fact that it's got exactly zero custom tooling or infrastructure behind it. It doesn't have artificial constraints on page organization; I can update it as soon as I've done something rather than waiting around for Bruce to do so; and there's an automatically maintained history of changes. Bruce has put a whole lot of man-hours into getting his page to do a few of the things we could do for free with the wiki page, but it's still got a long way to go. Now it would certainly be nice if there were some tools that would assist with dumping URLs for newly-arrived messages into the wiki page. Perhaps some of the pgsql-www crowd can think about how to do that. But even if we had to do that entirely by hand, I'd rather go with the wiki page. At some point it might be worth building the sort of heavy-duty infrastructure for the patch queue that you have in mind here. I don't think we need it yet, though, and I definitely don't think we understand our requirements well enough yet to start designing it. One of the reasons I like the wiki approach is exactly that there's such a low barrier to getting started with it. 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] Patch queue - wiki (was varadic patch)
Tom Lane wrote: For the past couple of weeks I've been dealing with both Bruce's queue and the one at http://wiki.postgresql.org/wiki/CommitFest:March and frankly I find the latter a *whole* lot more satisfactory, despite the fact that it's got exactly zero custom tooling or infrastructure behind it. It doesn't have artificial constraints on page organization; I can update it as soon as I've done something rather than waiting around for Bruce to do so; and there's an automatically maintained history of changes. Bruce has put a whole lot of man-hours into getting his page to do a few of the things we could do for free with the wiki page, but it's still got a long way to go. Now it would certainly be nice if there were some tools that would assist with dumping URLs for newly-arrived messages into the wiki page. Perhaps some of the pgsql-www crowd can think about how to do that. But even if we had to do that entirely by hand, I'd rather go with the wiki page. At some point it might be worth building the sort of heavy-duty infrastructure for the patch queue that you have in mind here. I don't think we need it yet, though, and I definitely don't think we understand our requirements well enough yet to start designing it. One of the reasons I like the wiki approach is exactly that there's such a low barrier to getting started with it. + MAXINT. 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] Patch queue - wiki (was varadic patch)
Tom Lane wrote: For the past couple of weeks I've been dealing with both Bruce's queue and the one at http://wiki.postgresql.org/wiki/CommitFest:March and frankly I find the latter a *whole* lot more satisfactory, despite the fact that it's got exactly zero custom tooling or infrastructure behind it. It doesn't have artificial constraints on page organization; I can update it as soon as I've done something rather than waiting around for Bruce to do so; and there's an automatically maintained history of changes. Bruce has put a whole lot of man-hours into getting his page to do a few of the things we could do for free with the wiki page, but it's still got a long way to go. Now it would certainly be nice if there were some tools that would assist with dumping URLs for newly-arrived messages into the wiki page. Perhaps some of the pgsql-www crowd can think about how to do that. But even if we had to do that entirely by hand, I'd rather go with the wiki page. At some point it might be worth building the sort of heavy-duty infrastructure for the patch queue that you have in mind here. I don't think we need it yet, though, and I definitely don't think we understand our requirements well enough yet to start designing it. One of the reasons I like the wiki approach is exactly that there's such a low barrier to getting started with it. It is not clear to me how a wiki can be easily created for 2k emails and then maintained in a reasonable way, or how emails can be added to it easily. There are several steps: o getting those 2k emails to start the commit fest o getting them into a wiki in a way that is fast/efficient o updating the wiki for changes efficiently Keep in mind the patch emails are pretty dynamic. As you get closer to the end of the commit fest, the wiki is easier because the list of open items becomes more stable. I am able to give others the ability to add, move, and delete emails in my patch queue, if desired. If people want to use the wiki, go ahead --- this would be one less job for me to do. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Patch queue permenent URLs
I have found a way to have permanent URLs that stay permanent even if the email is moved from the patches queue to the patches_hold queue. The trick is to use base to specify the base directory in the html. The new URLs look like: http://momjian.us/mhonarc/message-id/[EMAIL PROTECTED] The new URLs appear now. The old permanent will also remain active until the next commit fest. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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 queue permenent URLs
On Thu, 2008-03-27 at 11:18 -0400, Bruce Momjian wrote: The new URLs look like: http://momjian.us/mhonarc/message-id/[EMAIL PROTECTED] The new URLs appear now. The old permanent will also remain active until the next commit fest. If they are going to be permanent then they should reference a PostgreSQL project domain rather than a personal domain and a company one. Without disrespect to either, our emails should not rely on external domains. That way the project is in control, not the other way around. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk -- 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 queue permenent URLs
On Thu, Mar 27, 2008 at 3:44 PM, Simon Riggs [EMAIL PROTECTED] wrote: On Thu, 2008-03-27 at 11:18 -0400, Bruce Momjian wrote: The new URLs look like: http://momjian.us/mhonarc/message-id/[EMAIL PROTECTED] The new URLs appear now. The old permanent will also remain active until the next commit fest. If they are going to be permanent then they should reference a PostgreSQL project domain rather than a personal domain and a company one. Without disrespect to either, our emails should not rely on external domains. That way the project is in control, not the other way around. The company domain is from the message id by the looks of it - it should not be changed under any circumstances. -- Dave Page EnterpriseDB UK Ltd: http://www.enterprisedb.com PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk -- 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 queue permenent URLs
Simon Riggs wrote: On Thu, 2008-03-27 at 11:18 -0400, Bruce Momjian wrote: The new URLs look like: http://momjian.us/mhonarc/message-id/[EMAIL PROTECTED] The new URLs appear now. The old permanent will also remain active until the next commit fest. If they are going to be permanent then they should reference a PostgreSQL project domain rather than a personal domain and a company one. Without disrespect to either, our emails should not rely on external domains. That way the project is in control, not the other way around. Well, the patch queue maintained by Bruce has always been in his domain. And regarding the company domain, I note that that string is part of a Message-Id, generated by the patch submitter's machine, so entirely out of Bruce's (or anyone else's) control. Note that we will have permanent URLs by Message-Id in our archives soon too: if I have my way, they will look like http://archives.postgresql.org/msgid/[EMAIL PROTECTED] or something similar. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- 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 queue permenent URLs
Dave Page wrote: On Thu, Mar 27, 2008 at 3:44 PM, Simon Riggs [EMAIL PROTECTED] wrote: On Thu, 2008-03-27 at 11:18 -0400, Bruce Momjian wrote: The new URLs look like: http://momjian.us/mhonarc/message-id/[EMAIL PROTECTED] The new URLs appear now. The old permanent will also remain active until the next commit fest. If they are going to be permanent then they should reference a PostgreSQL project domain rather than a personal domain and a company one. Without disrespect to either, our emails should not rely on external domains. That way the project is in control, not the other way around. The company domain is from the message id by the looks of it - it should not be changed under any circumstances. Yep, the only way we can get rid of the company is to use an MD5 hash (which is what I used at first) instead of the message id, but people didn't like that. I have updated the permanent URL to be in the postgresql.org domain: http://momjian.postgresql.org/mhonarc/message-id/[EMAIL PROTECTED] Of course, momjian.us works too. (I am redirecting momjian.postgresql.org to momjian.us because the comments are bound to the domain name momjian.us.) -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- 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 queue needs update was:(PostgreSQL 8.4 development plan)
On Feb 6, 2008 1:52 PM, Alvaro Herrera [EMAIL PROTECTED] wrote: Josh Berkus escribió: I think we might want to do something along the lines of what Stefan set up (at least I think it was he) for the end of 8.4 on developer.postgresql.org. Bruce's patch list is easy to update, but hard to read. I'll put some effort into it. Easy to update for Bruce -- for anyone else it is impossible to update AFAIK. and, of course, will be things that escape from Bruce's eyes... for example, the Add GUC temp_tablespaces toprovide a default location for patch was actually committed in 8.3 and it's still on the patch queue http://momjian.us/mhonarc/patches_hold/msg0.html i think a depuration will be needed to keep the first commit fests simple... -- regards, Jaime Casanova Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning. Richard Cook ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Patch queue triage
On Wed, 2007-09-12 at 17:47 -0400, Bruce Momjian wrote: For those who have forgotten the progress we have made toward 8.3, here are the open patches we had for 8.3 as of May 1, 2006: Could you please issue a list of open items for 8.3? I want to check whether you are waiting on me for anything and which things have been deferred to next release. Thanks, -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Patch queue triage
Pavan Deolasee wrote: On 9/13/07, Bruce Momjian [EMAIL PROTECTED] wrote: For those who have forgotten the progress we have made toward 8.3, here are the open patches we had for 8.3 as of May 1, 2006: You mean May 1, 2007 ;-) Yea, sorry. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Patch queue triage
Simon Riggs wrote: On Wed, 2007-09-12 at 17:47 -0400, Bruce Momjian wrote: For those who have forgotten the progress we have made toward 8.3, here are the open patches we had for 8.3 as of May 1, 2006: Could you please issue a list of open items for 8.3? I want to check whether you are waiting on me for anything and which things have been deferred to next release. I am working on putting them all in the patch queue now. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Patch queue triage
For those who have forgotten the progress we have made toward 8.3, here are the open patches we had for 8.3 as of May 1, 2006: --- Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: FYI, Tom, Heikki, I need one of you to post the list of patches and where we think we are on each one, even if the list is imperfect. This message is an attempt to sort out which patch queue entries have no hope of getting into 8.3 (and so we shouldn't spend more time on them right now), which ones can get in but are waiting on their authors for more work, and which ones are ready for immediate review. You'll notice that numerically quite a lot of the patches fall into the dead category. This isn't actually all that surprising because if they were apply-able they'd have gotten in. (It's not like we've completely neglected applying patches for the last six months...) However, many of the remaining live patches are huge ones, like HOT and delayed commit, and are going to consume considerable review effort (again, if they didn't, they might have been in already). The bottom line is that we are desperately in need of more review manpower. I'm pleased to report that Heikki Linnakangas has promised to devote most of the next few weeks to helping review, and has already picked out some patches he feels qualified to work on, as you'll see below. I have also been coordinating reviewing assignments off-list with Neil and Magnus to avoid duplication of effort. But I'd like to encourage everyone who's done any backend hacking to look at the live patches not shown as assigned to someone specific. The more eyeballs the better; anything you catch is something someone else might miss. Also, several of the open patches are in need of more performance testing, so if you can help out in that fashion please do so. With that, the patches: * Re: [pgsql-patches] [PATCHES] [HACKERS] [Fwd: Index Advisor] /Gurjeet Singh/ I don't think this can be applied in anything like its current state. The internal interface to the planner is not very good, and ditto for the user API. What I would suggest trying to do is get a set of plugin hooks defined for the planner that would allow the advisor to be implemented entirely as an external module, and then let it be worked on as a pgfoundry project. I have some ideas about appropriate design of the plugin hooks (as mentioned in my review message of a month ago), but I have to say that getting that done for 8.3 is lower-priority than some of the other patches. * [pgsql-patches] Ctid chain following enhancement /Pavan Deolasee/ I'm not very excited about this --- it seems to me to complicate the code in some places that are not in fact performance-critical. While it doesn't seem likely to break things, I'm not in favor of reducing code readability unless a measurable performance improvement can be shown. Can we have some tests showing this is worthwhile? * [PATCHES] Error correction for n_dead_tuples /ITAGAKI Takahiro/ Waiting for OldestXmin patch to be accepted or rejected. However, regardless of the fate of that patch, I'm concerned that this one creates an open-loop behavior in which the n_dead_tuples estimate will diverge arbitrarily far from reality over time. I criticized the original proposal on that basis, and I'm not convinced this version fixes it, because of the fact that stats counter updates occur much later than the actions they count. (My recent patch to rate-limit tabstat messages made that problem worse, but it existed anyway.) What might make sense is for vacuum to count the number of dead-but-not-removable tuples it skips over, and apply that as the value of n_dead_tuples on receipt of the vacuum message (instead of setting to zero as now). This is likely to be wrong with respect to the actions of transactions running concurrently with the vacuum, but I think so is the proposed patch; and at least in this form the error certainly cannot accumulate across vacuum cycles. * [PATCHES] Table function support /Pavel Stehule/ Neil has promised to review this. AFAIK there are no showstoppers but there are some disagreements on the details of the functionality. * [HACKERS] Grouped Index Tuples /Heikki Linnakangas/ * [HACKERS] Grouped Index Tuples / Clustered Indexes /Heikki Linnakangas/ Needs review. I'm not sure how many people besides Heikki have really looked at this (I know I haven't). * Re: [PATCHES] POSIX shared memory support /Chris Marcellino/ I'm not convinced that we want this at all. The original proposal was to provide an alternative for platforms without SysV shmem support, but the working versions of the patch fail to remove the SysV dependency, and the portability of this code is itself quite unproven. Do we really want to take on maintenance of
Re: [HACKERS] Patch queue triage
On 9/13/07, Bruce Momjian [EMAIL PROTECTED] wrote: For those who have forgotten the progress we have made toward 8.3, here are the open patches we had for 8.3 as of May 1, 2006: You mean May 1, 2007 ;-) Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com
Re: [HACKERS] Patch queue triage
Tom Lane wrote: At this point it seems nothing will be done about this issue for 8.3. * [PATCHES] plpgpsm /Pavel Stehule/ I think this has to be held for 8.4: it was submitted too late for the 8.3 feature deadline, and in fact I don't recall that there was any community discussion/consensus on accepting it into core at all. Another big problem is that it largely copies-and-pastes the plpgsql code, which I think is an unacceptable maintenance burden in the long run. We need to consider whether we can't refactor to avoid code duplication. Per my updated patch email to the lists yesterday, plus Toms' above comments *and* Alvaro's comments to me when I asked Alexey to review it... may I strongly suggest that we bounce this for further development in 8.4. Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Patch queue triage
Pavan Deolasee wrote: I suppose inserting HOT tuples without index maintenance is useful even if no changes to the space allocation is made is useful. It won't get the space usage but it would save on index thrashing. But that still implies all the code to handle scans, updates, index builds, etc. Those chunks could be separated out but you can't commit without them. There are few things that we can separate easily, like CREATE INDEX related changes, VACUUM and VACUUM FULL related changed, space reuse related changes etc. Let me give it a shot. Did we ever get a broken up patch for this? Joshua D. Drake Thanks, Pavan -- EnterpriseDB http://www.enterprisedb.com -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Patch queue triage
Joshua D. Drake wrote: Tom Lane wrote: At this point it seems nothing will be done about this issue for 8.3. * [PATCHES] plpgpsm /Pavel Stehule/ I think this has to be held for 8.4: it was submitted too late for the 8.3 feature deadline, and in fact I don't recall that there was any community discussion/consensus on accepting it into core at all. Another big problem is that it largely copies-and-pastes the plpgsql code, which I think is an unacceptable maintenance burden in the long run. We need to consider whether we can't refactor to avoid code duplication. Per my updated patch email to the lists yesterday, plus Toms' above comments *and* Alvaro's comments to me when I asked Alexey to review it... may I strongly suggest that we bounce this for further development in 8.4. Agreed. Done. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Patch queue triage
On 5/17/07, Joshua D. Drake [EMAIL PROTECTED] wrote: Pavan Deolasee wrote: There are few things that we can separate easily, like CREATE INDEX related changes, VACUUM and VACUUM FULL related changed, space reuse related changes etc. Let me give it a shot. Did we ever get a broken up patch for this? I broke the patch into 5 smaller, logical pieces and posted them on May 7th. Thanks, Pavan -- Pavan Deolasee EnterpriseDB http://www.enterprisedb.com
Re: [HACKERS] Patch queue triage
Joshua D. Drake wrote: Pavan Deolasee wrote: I suppose inserting HOT tuples without index maintenance is useful even if no changes to the space allocation is made is useful. It won't get the space usage but it would save on index thrashing. But that still implies all the code to handle scans, updates, index builds, etc. Those chunks could be separated out but you can't commit without them. There are few things that we can separate easily, like CREATE INDEX related changes, VACUUM and VACUUM FULL related changed, space reuse related changes etc. Let me give it a shot. Did we ever get a broken up patch for this? Yes: http://archives.postgresql.org/pgsql-patches/2007-05/msg00065.php -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Patch queue triage
Heikki Linnakangas wrote: There are few things that we can separate easily, like CREATE INDEX related changes, VACUUM and VACUUM FULL related changed, space reuse related changes etc. Let me give it a shot. Did we ever get a broken up patch for this? Yes: http://archives.postgresql.org/pgsql-patches/2007-05/msg00065.php Thanks :). Sincerely, Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Patch queue triage
Sorry for late responce due to very long vacation season in Japan. Tom Lane wrote: * Re: [PATCHES] [HACKERS] Full page writes improvement, code update /Koichi Suzuki/ I feel that we have to insist that this be modified to not create any WAL bloat in the pre-compression form. That will be more efficient and will avoid the whole argument about whether a switch is needed. There was also doubt about whether the external programs (pg_compresslog etc) were ready for prime time. At this point we could accept a patch that makes whatever small tweaks are needed to ensure that an incremental-format WAL record can be extracted from a full-page-write record, at least for the most common WAL record types for which compression is actually important. I think the actual compression/decompression programs could undergo further development on pgfoundry with an eye to merging them into core before 8.4 release. As suggested by Tom, I agree that WAL should not include both full page write and incremental (logical) log. I began to examine WAL record format to see if incremental log can be made from full page writes. It will be okay even before 8.4, if simplified patch to the core is accepted. I will post simplified patch to the core as follows: 1. Mark the flag to indicate that the WAL record is compressable from full page writes to incremental log. This flag will be set if a) It is not written during the hot backup, and b) Archive command is active, and c) WAL contains full page writes, and d) full_page_writes=on. No logical log will be written to WAL in this case, and 2. During recovery, xl_tot_len check will be skipped for compressed WAL records. With this patch, compress/decompress can be developped outside the core. I'd like to post them to PG foundary first for the review for 8.4. I'd be very grateful if this patch can be considered again. Best Regards; Koichi Suzuki ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Patch queue triage
On 5/2/07, Gregory Stark [EMAIL PROTECTED] wrote: Can we? I mean, sure you can break the patch up into chunks which might make it easier to read, but are any of the chunks useful alone? Well I agree, it would be a tough job. I can try and break the patch into several self-complete incremental patches which compile and work, but I am worried about missing something somewhere and/or inserting any bugs in the process. I suppose inserting HOT tuples without index maintenance is useful even if no changes to the space allocation is made is useful. It won't get the space usage but it would save on index thrashing. But that still implies all the code to handle scans, updates, index builds, etc. Those chunks could be separated out but you can't commit without them. There are few things that we can separate easily, like CREATE INDEX related changes, VACUUM and VACUUM FULL related changed, space reuse related changes etc. Let me give it a shot. Thanks, Pavan -- EnterpriseDB http://www.enterprisedb.com
Re: [HACKERS] Patch queue triage
On 5/2/07, Tom Lane [EMAIL PROTECTED] wrote: * [PATCHES] HOT Patch - Ready for review /Pavan Deolasee/ This needs a *lot* of review. Can we break it down into more manageable chunks? I'm not sure that anyone's got a full grasp of the implications of this patch, and that's a scary thought. Sure, we can do that. I actually did that when I posted the incremental versions of the HOT-patch, each version implementing the next big chunk of the code. I can reverse engineer that again. When I do that, should I just break the patch into logical pieces without worrying about whether each piece alone builds/works correcttly ? Or should I try to make each piece complete ? I know the second would be a preferred way, but it would be more work. But if that can considerably ease review process, I would do that by all means. In any case, there will be dependecies amongst the patches. I am on leave today, so would start on this tomorrow. Thanks, Pavan -- EnterpriseDB http://www.enterprisedb.com
Re: [HACKERS] Patch queue triage
On Tue, 1 May 2007, Tom Lane wrote: * [HACKERS] tsearch_core patch for inclusion /Teodor Sigaev/ Have we resolved whether the API and the dump/restore strategy are acceptable? The code needs review too, but not till we've settled on the basic question whether we like the feature set. There were several discussion and we tried to satisfy a claims. We added the ability of creation of FTS with one command (just create GIN index on text attribute), which many people like a lot, we changed SQL syntax to be more SQL-ish and we like it. We discussed the new FTS on two conferences in Moscow and got positive opinions. Also, we wrote FTSBOOK ( http://mira.sai.msu.su/~megera/pgsql/ftsdoc/ ) in english and FTS introduction in russian ( http://www.sai.msu.su/~megera/postgres/talks/fts_pgsql_intro.html ). For the period from the patch was announced there were 3100 unique IP, which downloaded FTSBOOK. Regards, Oleg _ Oleg Bartunov, Research Scientist, Head of AstroNet (www.astronet.ru), Sternberg Astronomical Institute, Moscow University, Russia Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(495)939-16-83, +007(495)939-23-83 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Patch queue triage
Hello Tom, All what you wrote is true. plpgpsm copies-and-pastes about 30% of code and It is terrible for long run. But when I can change it? Writing differnt runtime is nonsense, better way is refactoring plpgsql and then sharing code with its. It's not propable in 8.4 .. there will by lot of important patches from 8.3, and it's mean so interpret wll not be in core before two years. All your last patches I merged in one day. In next months plpgpsm can follow plpgsql, or else. plpgpsm can be experimental and can be used for integration into core and creating SQL procedural language API in 8.5 (and plpgsql will be in 8.4, 8.5 without changes) and in 8.6 plpgsql will be modified to use this API. This road expect stable plpgsql for next two, three years. plpgpsm can solve some questions about future plpgsql. It contains some others construct which is foreign in plpgsql and plpgsql can be in Oracle's style forever (with David's patch Oracle collections are possible). Bigger problem for plpgpsm isn't runtime but users. It needs bigger discuss about integration into core, and it isn't possible without integration into core. Current API can be dismissed in others API. With variable API we can drop variables substitution in SQL, FAST SQL call can be part of SPI. But all needs time. From plpgsql view simple change of caching was big patch. I will be happy if 8.4 will contains true session variables. It can be used in SQL languages later. I afraid so all these steps needs long time. plpgpsm is ready. It's patch without dependencies and has not influence to other parts of postgresql. I am working on documentation now. Czech version is completed, waiting for translation to english. Regards Pavel Stehule * [PATCHES] plpgpsm /Pavel Stehule/ I think this has to be held for 8.4: it was submitted too late for the 8.3 feature deadline, and in fact I don't recall that there was any community discussion/consensus on accepting it into core at all. Another big problem is that it largely copies-and-pastes the plpgsql code, which I think is an unacceptable maintenance burden in the long run. We need to consider whether we can't refactor to avoid code duplication. _ Najdete si svou lasku a nove pratele na Match.com. http://www.msn.cz/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Patch queue triage
* [PATCHES] Updateable cursors patch /FAST PostgreSQL/ This is incomplete, and I fear at this point has to be held over to 8.4. It is true that my original patch post said that I need to modify the patch to work with tidscan. Since then I have realized that this modification is not needed as it would have the same result as the 'branching out from sequential scan' solution currently implemented. I was hoping that I could discuss this with whoever picks up the patch for review before doing modifications if any is needed. So in my humble opinion, it would be great if this can be considered for 8.3 as there are not many modifications needed. P.S. Only Simon commented on my original patch. Simon, do you have time to revisit the patch so that we could discuss this? Rgds, Arul Shaji ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Patch queue triage
Pavan Deolasee [EMAIL PROTECTED] writes: On 5/2/07, Tom Lane [EMAIL PROTECTED] wrote: This needs a *lot* of review. Can we break it down into more manageable chunks? Sure, we can do that. I actually did that when I posted the incremental versions of the HOT-patch, each version implementing the next big chunk of the code. I can reverse engineer that again. Can we? I mean, sure you can break the patch up into chunks which might make it easier to read, but are any of the chunks useful alone? I suppose inserting HOT tuples without index maintenance is useful even if no changes to the space allocation is made is useful. It won't get the space usage but it would save on index thrashing. But that still implies all the code to handle scans, updates, index builds, etc. Those chunks could be separated out but you can't commit without them. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Patch queue triage
Tom Lane [EMAIL PROTECTED] writes: Bruce Momjian [EMAIL PROTECTED] writes: FYI, Tom, Heikki, I need one of you to post the list of patches and where we think we are on each one, even if the list is imperfect. This message is an attempt to sort out which patch queue entries have no hope of getting into 8.3 (and so we shouldn't spend more time on them right now), which ones can get in but are waiting on their authors for more work, and which ones are ready for immediate review. Thanks for this. This is exactly what we've been missing recently I think. * [PATCHES] non-recursive WITH clause support /Gregory Stark/ I think the consensus is that we should wait for a more complete WITH implementation to be submitted, since this one creates compatibility issues without any real return in the form of added functionality. I submitted it because it filled in a missing ANSI feature but nobody's piped up saying they missed that feature so, sure. * [PATCHES] Concurrent psql v4 [WIP] /stark/ This is waiting on the author to change the API per list discussions; we can't apply something that is about to have some commands removed ... I did finish the api changes -- though I'm not too happy with the names. I was expecting the list to play the name game so I just put in placeholder names originally. I'm adding documentation and example regression tests now. Also I'm trying to fix the cursor-mode FETCH_COUNT support which it breaks. I'm thinking of once the first batch of rows arrives just going into a synchronous function to fetch the rest of the resultsets. * Re: [HACKERS] Modifying TOAST thresholds /Tom Lane/ At this point it seems nothing will be done about this issue for 8.3. I'm not sure anyone has an idea how to test it. TPCC isn't really useful because it has a fixed size (500 byte) string buffer. Perhaps if we modified it to have a random string length uniformly distributed between 0-2k ? But even then it never does any scans based on that buffer. But the problem with going with something more natural is that it'll be harder to tell exactly what it's testing. * [HACKERS] tsearch_core patch for inclusion /Teodor Sigaev/ Have we resolved whether the API and the dump/restore strategy are acceptable? The code needs review too, but not till we've settled on the basic question whether we like the feature set. Personally I actually do like the idea of promoting tsearch to first-class citizen by giving it keywords and a place in the grammar. I think it's a more fully integrated interface than the function based one. The only reason I might think otherwise was if it was just a crutch for missing features it had exposed that would be better implemented more generically. But I don't think that's the case. * Re: [PATCHES] [Fwd: Deferred Transactions, Transaction Guarantee and COMMITwithout waiting] /Simon Riggs/ Simon is on the hook to submit an updated patch. I hope this one makes it in, as it looks like a really nice performance improvement for those who can use it; but the original patch seems overcomplicated. I know Simon's really busy. I might be able to help with it if he wants. * Re: [PATCHES] LIMIT/SORT optimization /Gregory Stark/ * [PATCHES] updated SORT/LIMIT patch /Gregory Stark/ I will look at this. I recall being concerned about whether there wasn't a cleaner way to introduce the required inter-node communication. The next big thing to keep in mind in this area is a unique sort which would need to know if there's a Unique node above it with the same key. If the resulting inter-node communication arrangement has your blessing and can handle that as well then I'll probably do that for 8.4. Incidentally I would prefer it if you want to make changes that you explain the changes to me and let me make them. It gives me a better chance to understand what the changes really are and the motivation than trying to read a patch later and understand why you made the changes you did. I understand sometimes it's easier to just write the code than to explain the idea to someone else and then review the resulting code though and there's already enough work your plate so if that's the case then so be it. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Patch queue triage
On Tue, May 01, 2007 at 10:44:38PM -0400, Tom Lane wrote: * [PATCHES] Preliminary GSSAPI Patches /Henry B. Hotz/ Magnus is reviewing this one. Check. * [PATCHES] Clear up strxfrm() in UTF-8 with locale on Windows /ITAGAKI Takahiro/ Someone else needs to look at this; I can't test it. Magnus? Yup, it's on my list. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Patch queue triage
Gregory Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Bruce Momjian [EMAIL PROTECTED] writes:
FYI, Tom, Heikki, I need one of you to post the list of patches and
where we think we are on each one, even if the list is imperfect.
This message is an attempt to sort out which patch queue entries have
no hope of getting into 8.3 (and so we shouldn't spend more time on them
right now), which ones can get in but are waiting on their authors for
more work, and which ones are ready for immediate review.
Thanks for this. This is exactly what we've been missing recently I think.
100% agree.
* Re: [HACKERS] Modifying TOAST thresholds /Tom Lane/
At this point it seems nothing will be done about this issue for 8.3.
I'm not sure anyone has an idea how to test it. TPCC isn't really useful
because it has a fixed size (500 byte) string buffer. Perhaps if we modified
it to have a random string length uniformly distributed between 0-2k ? But
even then it never does any scans based on that buffer. But the problem with
going with something more natural is that it'll be harder to tell exactly what
it's testing.
My idea on this was to create two backends, one with the default TOAST
value, and a second with a value of 50 bytes. Create a table with one
TEXT field, and several other columns, each column 50 bytes.
Then, fill the table with random data (script attached that might help),
and the try 2000, 1500, 1000, etc, bytes in the TEXT column for each row
(use random data so the compression code doesn't shrink it). Then run a
test with both backends acessing the TEXT column and non-TEXT column and
measure the difference between the two backends, i.e. the backend with a
TOAST value of 50 should show faster access on the non-TEXT field, but
slower access on the TEXT field.
Then, figure out where the gains on the non-TEXT field seem to diminish
in usefulness. Basically, with a lower TOAST value, we are going to
spend more time accessing the TEXT field, but the speedup for the
non-TEXT field should be large enough win that we don't care. As the
TEXT column becomes shorter, it has less affect on the non-TEXT access.
--
Bruce Momjian [EMAIL PROTECTED] http://momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
:
ROWS=10
COLSIZE=2500
echo
DROP TABLE test;
CREATE TABLE test(i SERIAL, t text);
INSERT INTO test (t)
SELECT array_to_string(ARRAY(
SELECT chr(32 + (95 * random())::integer)
FROM generate_series(1,$COLSIZE)),'')
FROMgenerate_series(1, $ROWS);
SELECT pg_relation_size('test') AS HEAP,
pg_total_relation_size('test') - pg_relation_size('test') AS
TOAST;
SET log_min_duration_statement = 0;
SET client_min_messages = 'log';
SELECT t FROM test WHERE i = 234329823; |
sql test
---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
Re: [HACKERS] Patch queue triage
Bruce Momjian [EMAIL PROTECTED] writes: Then, figure out where the gains on the non-TEXT field seem to diminish in usefulness. Basically, with a lower TOAST value, we are going to spend more time accessing the TEXT field, but the speedup for the non-TEXT field should be large enough win that we don't care. As the TEXT column becomes shorter, it has less affect on the non-TEXT access. I guess the key is to break down what it is we want to measure into several parts. These can each be measured precisely for various sized TOASTed data. Costs: 1) cost of retrieving data from TOAST pointer versus retrieving data from inline tuple. We just want the absolute time difference between the two operations, not the percentage difference. 2) cost of creating TOAST pointer (ie, inserting a new tuple with a TOAST pointer or updating a previously inlined tuple to have a TOASTed column). 3) cost of deleting a TOAST pointer (ie, deleting a tuple or updating a tuple to no longer have a TOASTed column) 3) cost of deleting a tuple with an existing TOAST pointer (or updating a tuple to be all inlined) versus deleting an plain tuple or updating a plain tuple. Savings: 1) time savings accessing a tuple without retrieving the TOAST pointer versus having to access the tuple with the data inlined. 2) time savings updating a tuple without modifying toasted data versus updating same tuple with the data inlined in both versions. The plan you described would be testing costs 1 and savings 1 but I think we need to continue to the others as well. Then the trick is to somehow make some argument about the frequency of the various operations and the acceptable tradeoff. I think you're right that the time spent accessing the data would be the most important metric. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Patch queue triage
Another complexity is testing cases where the table fits in shared memory/RAM, and those that don't, and testing cases where heap fits in RAM only because we pushed things to TOAST, and cases where we have to do lots of TOAST access that doesn't fit in RAM. I wonder if it is even worth testing it because pushing more to TOAST probably means the more frequently accessed data is in RAM. Anyway, how is going to run these tests? --- Gregory Stark wrote: Bruce Momjian [EMAIL PROTECTED] writes: Then, figure out where the gains on the non-TEXT field seem to diminish in usefulness. Basically, with a lower TOAST value, we are going to spend more time accessing the TEXT field, but the speedup for the non-TEXT field should be large enough win that we don't care. As the TEXT column becomes shorter, it has less affect on the non-TEXT access. I guess the key is to break down what it is we want to measure into several parts. These can each be measured precisely for various sized TOASTed data. Costs: 1) cost of retrieving data from TOAST pointer versus retrieving data from inline tuple. We just want the absolute time difference between the two operations, not the percentage difference. 2) cost of creating TOAST pointer (ie, inserting a new tuple with a TOAST pointer or updating a previously inlined tuple to have a TOASTed column). 3) cost of deleting a TOAST pointer (ie, deleting a tuple or updating a tuple to no longer have a TOASTed column) 3) cost of deleting a tuple with an existing TOAST pointer (or updating a tuple to be all inlined) versus deleting an plain tuple or updating a plain tuple. Savings: 1) time savings accessing a tuple without retrieving the TOAST pointer versus having to access the tuple with the data inlined. 2) time savings updating a tuple without modifying toasted data versus updating same tuple with the data inlined in both versions. The plan you described would be testing costs 1 and savings 1 but I think we need to continue to the others as well. Then the trick is to somehow make some argument about the frequency of the various operations and the acceptable tradeoff. I think you're right that the time spent accessing the data would be the most important metric. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Patch queue triage
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: FYI, Tom, Heikki, I need one of you to post the list of patches and where we think we are on each one, even if the list is imperfect. This message is an attempt to sort out which patch queue entries have no hope of getting into 8.3 (and so we shouldn't spend more time on them right now), which ones can get in but are waiting on their authors for more work, and which ones are ready for immediate review. Excellent list. I have a little time available now, so I'll work on some, starting with trying to complete arrays of complex types. cheers andrew ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Patch queue triage
Tom Lane wrote: * [pgsql-patches] Ctid chain following enhancement /Pavan Deolasee/ I'm not very excited about this --- it seems to me to complicate the code in some places that are not in fact performance-critical. While it doesn't seem likely to break things, I'm not in favor of reducing code readability unless a measurable performance improvement can be shown. Can we have some tests showing this is worthwhile? IIRC this patch was originally part of an old HOT patch, and it was submitted as a separate patch because it has some benefit on its own but more importantly getting it applied first would make the HOT patch slightly smaller. I'm not sure if the latest HOT patch requires or includes this change anymore. If not we should drop this. If it does, then let's deal with this before attacking the hard core of HOT. * [HACKERS] Grouped Index Tuples /Heikki Linnakangas/ * [HACKERS] Grouped Index Tuples / Clustered Indexes /Heikki Linnakangas/ Needs review. I'm not sure how many people besides Heikki have really looked at this (I know I haven't). The patch is ugly as it is. We need API changes to make it less ugly, I had hoped to discuss and reach consensus on them well before feature freeze, that's what the indexam API proposal and Stream bitmaps threads in the patch queue are all about. But those discussions and patches stalled, so the clustered index patch is still in the same ugly state. I'm afraid we're getting past due on clustered indexes. The patch isn't ready for committing as it is, and we still don't have agreement on the API changes or even on the design in general. :( * [HACKERS] Stream bitmaps /Heikki Linnakangas/ I think this is on hold unless a finished bitmap-index patch shows up; however there was some discussion of using this in support of clustered indexes, so maybe it's live anyway? Heikki? This particular thread is closely related to bitmap indexes. But see next item: * Re: [HACKERS] [PATCHES] Bitmapscan changes /Heikki Linnakangas/ I had objected to this on the grounds that it seemed to be covering only a narrow territory between HOT and bitmap indexes, but given the probability that one or even both of those won't make it, we need to give this one a second look. So: live, needs review. Are you talking about the patch I submitted at the beginning of that thread? Because the mail in the patch queue is actually about whether or not we want clustered indexes. I think the original bitmapscan changes patch I submitted is live and needs review, even if clustered indexes and bitmap indexes are rejected. It should give some performance benefit when you do bitmap ANDs with partially lossy bitmaps, and from setting bits directly in the bitmap in the indexam in one call, instead of calling amgetmulti many times. Though I never measured that. * [HACKERS] Indexam interface proposal /Heikki Linnakangas/ AFAICS this discussion died out with no actual patch submitted. This is part of clustered indexes.. This was my proposal of what the indexam API changes would be like. This patch is either live or dead together with clustered indexes. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Patch queue triage
http://www.sigaev.ru/misc/tsearch_core-0.46.gz Patch is synced with current CVS HEAD and synced with bugfixes in contrib/tsearch2 -- Teodor Sigaev E-mail: [EMAIL PROTECTED] WWW: http://www.sigaev.ru/ ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Patch queue triage
On Tue, 2007-05-01 at 22:44 -0400, Tom Lane wrote: Nice summary Tom. * Re: [PATCHES] [Fwd: Deferred Transactions, Transaction Guarantee and COMMITwithout waiting] /Simon Riggs/ Simon is on the hook to submit an updated patch. I hope this one makes it in, as it looks like a really nice performance improvement for those who can use it; but the original patch seems overcomplicated. It will, but it will be next week now. Changes agreed though. * [PATCHES] Minor recovery changes /Simon Riggs/ The submission mentions open issues --- when will those be resolved? Should we apply the patch-so-far anyway? Patch is OK to go in as-is. There are open issues, but they need more thought and discussion and I regret won't happen in a reasonable timescale due to other work. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] Patch queue triage
Bruce Momjian [EMAIL PROTECTED] writes: FYI, Tom, Heikki, I need one of you to post the list of patches and where we think we are on each one, even if the list is imperfect. This message is an attempt to sort out which patch queue entries have no hope of getting into 8.3 (and so we shouldn't spend more time on them right now), which ones can get in but are waiting on their authors for more work, and which ones are ready for immediate review. You'll notice that numerically quite a lot of the patches fall into the dead category. This isn't actually all that surprising because if they were apply-able they'd have gotten in. (It's not like we've completely neglected applying patches for the last six months...) However, many of the remaining live patches are huge ones, like HOT and delayed commit, and are going to consume considerable review effort (again, if they didn't, they might have been in already). The bottom line is that we are desperately in need of more review manpower. I'm pleased to report that Heikki Linnakangas has promised to devote most of the next few weeks to helping review, and has already picked out some patches he feels qualified to work on, as you'll see below. I have also been coordinating reviewing assignments off-list with Neil and Magnus to avoid duplication of effort. But I'd like to encourage everyone who's done any backend hacking to look at the live patches not shown as assigned to someone specific. The more eyeballs the better; anything you catch is something someone else might miss. Also, several of the open patches are in need of more performance testing, so if you can help out in that fashion please do so. With that, the patches: * Re: [pgsql-patches] [PATCHES] [HACKERS] [Fwd: Index Advisor] /Gurjeet Singh/ I don't think this can be applied in anything like its current state. The internal interface to the planner is not very good, and ditto for the user API. What I would suggest trying to do is get a set of plugin hooks defined for the planner that would allow the advisor to be implemented entirely as an external module, and then let it be worked on as a pgfoundry project. I have some ideas about appropriate design of the plugin hooks (as mentioned in my review message of a month ago), but I have to say that getting that done for 8.3 is lower-priority than some of the other patches. * [pgsql-patches] Ctid chain following enhancement /Pavan Deolasee/ I'm not very excited about this --- it seems to me to complicate the code in some places that are not in fact performance-critical. While it doesn't seem likely to break things, I'm not in favor of reducing code readability unless a measurable performance improvement can be shown. Can we have some tests showing this is worthwhile? * [PATCHES] Error correction for n_dead_tuples /ITAGAKI Takahiro/ Waiting for OldestXmin patch to be accepted or rejected. However, regardless of the fate of that patch, I'm concerned that this one creates an open-loop behavior in which the n_dead_tuples estimate will diverge arbitrarily far from reality over time. I criticized the original proposal on that basis, and I'm not convinced this version fixes it, because of the fact that stats counter updates occur much later than the actions they count. (My recent patch to rate-limit tabstat messages made that problem worse, but it existed anyway.) What might make sense is for vacuum to count the number of dead-but-not-removable tuples it skips over, and apply that as the value of n_dead_tuples on receipt of the vacuum message (instead of setting to zero as now). This is likely to be wrong with respect to the actions of transactions running concurrently with the vacuum, but I think so is the proposed patch; and at least in this form the error certainly cannot accumulate across vacuum cycles. * [PATCHES] Table function support /Pavel Stehule/ Neil has promised to review this. AFAIK there are no showstoppers but there are some disagreements on the details of the functionality. * [HACKERS] Grouped Index Tuples /Heikki Linnakangas/ * [HACKERS] Grouped Index Tuples / Clustered Indexes /Heikki Linnakangas/ Needs review. I'm not sure how many people besides Heikki have really looked at this (I know I haven't). * Re: [PATCHES] POSIX shared memory support /Chris Marcellino/ I'm not convinced that we want this at all. The original proposal was to provide an alternative for platforms without SysV shmem support, but the working versions of the patch fail to remove the SysV dependency, and the portability of this code is itself quite unproven. Do we really want to take on maintenance of yet-another shmem implementation just to let people be lazy about changing their SHMMAX settings? As best I can tell the main problem in that department is Darwin, and it'd be a whole lot simpler if Apple just raised their darn default SHMMAX to something that's sensible for the 21st century. [BTW, there was a
Re: [HACKERS] Patch queue triage
On Tue, 1 May 2007, Tom Lane wrote: * Re: [PATCHES] Synchronized Scan WIP patch /Simon Riggs/ Heikki is reviewing this one. Also I believe Greg Smith is doing more performance testing. Actually it was the Automatic adjustment of bgwriter_lru_maxpages patch from Itagaki Takahiro I've been working on--which, by the way, Bruce sent out a note about the other day saying was already booted into 8.4. I've integrated a part of the LRU patch usefully into the new pg_stat_bgwriter, renamed some variables around accordingly, cleanup I felt had to preceed performance testing. Heikki might want to wait for me to finish that before putting time into it. The buffer allocation monitoring part would be useful to apply even if the GUC and behavior changes are deemed outside of the 8.3 scope. Also, I think I was the most vocal participant in the COPY-able sql log outputs feature discussion and therefore was planning to do what review what I can of the final patch API immediately afterwards. I try not to complain about things unless I'm willing to help fix them. -- * Greg Smith [EMAIL PROTECTED] http://www.gregsmith.com Baltimore, MD ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Patch queue triage
Greg Smith [EMAIL PROTECTED] writes: On Tue, 1 May 2007, Tom Lane wrote: * Re: [PATCHES] Synchronized Scan WIP patch /Simon Riggs/ Heikki is reviewing this one. Also I believe Greg Smith is doing more performance testing. Actually it was the Automatic adjustment of bgwriter_lru_maxpages patch from Itagaki Takahiro I've been working on--which, by the way, Bruce sent out a note about the other day saying was already booted into 8.4. It's still on the patch queue list, and Heikki and I were assuming it was still live. I've integrated a part of the LRU patch usefully into the new pg_stat_bgwriter, renamed some variables around accordingly, cleanup I felt had to preceed performance testing. Heikki might want to wait for me to finish that before putting time into it. The buffer allocation monitoring part would be useful to apply even if the GUC and behavior changes are deemed outside of the 8.3 scope. Also, I think I was the most vocal participant in the COPY-able sql log outputs feature discussion and therefore was planning to do what review what I can of the final patch API immediately afterwards. I try not to complain about things unless I'm willing to help fix them. Great, you're on the hook for both of those ;-) regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Patch queue triage
On 5/2/07, Tom Lane [EMAIL PROTECTED] wrote: * [pgsql-patches] Ctid chain following enhancement /Pavan Deolasee/ I'm not very excited about this --- it seems to me to complicate the code in some places that are not in fact performance-critical. While it doesn't seem likely to break things, I'm not in favor of reducing code readability unless a measurable performance improvement can be shown. Can we have some tests showing this is worthwhile? I am OK with dropping this for the time being. It came out of code reading. I would later run some tests to see if it really gives any performance benefit. Thanks, Pavan -- EnterpriseDB http://www.enterprisedb.com
Re: [HACKERS] Patch queue concern
My feeling is we should have more regular sync points where the patch queue is emptied and everything committed or rejected. No doubt, but the real problem here is that reviewing/committing other people's patches is not fun, it's just work :-(. So it's no surprise that it tends to get put off. Not sure what to do about that. In my experience it mostly pays to keep people directly responsible for their own work. Every intermediate tester/reviewer/coordinator tends to reduce the submitter's feeling for responsibility. So I could imagine a modus operandi where a submitter states: I feel confident that you can commit without review and will be availabe for fixes/additional work required. Maybe we have that in the form of committers that commit their own work already. But I do feel that some patches Bruce is talking about need aggreement and help, not only review. Andreas ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Patch queue concern
On Thu, 2007-03-29 at 01:34 -0400, Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: My feeling is we should have more regular sync points where the patch queue is emptied and everything committed or rejected. No doubt, but the real problem here is that reviewing/committing other people's patches is not fun, it's just work :-(. Gosh, you always seemed to enjoy my patches so much ;-) We can all see how hard you and Bruce work and its very much appreciated, even if we don't often say so. That's why everybody else works so hard too. Sometimes we only communicate the tensions caused by external expectations. So it's no surprise that it tends to get put off. Not sure what to do about that. Well, one thing I can do is say Thanks now and try to do that more regularly in the future. The enjoyment you and others take from working on PostgreSQL is infectious, so whatever else we do its gotta stay fun. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Patch queue concern
Tom Lane [EMAIL PROTECTED] writes: Simon Riggs [EMAIL PROTECTED] writes: My feeling is we should have more regular sync points where the patch queue is emptied and everything committed or rejected. No doubt, but the real problem here is that reviewing/committing other people's patches is not fun, it's just work :-(. So it's no surprise that it tends to get put off. Not sure what to do about that. Obviously a big part of that is that we just don't have enough committers. I'm hopeful that in time that situation will improve but in the meantime we do have a problem and the burden falls unfairly on a few. Is there anything others can do to help? If non-committers like Simon or I reviewed patches would it be easier for you to give a quick agreement to the comments or that's not an issue comment? It seems like we do have a few committers who should be able to review code quality but are uncertain about making major design decisions. If, for example, Bruce or Jan reviewed patches more invasive than they usually do for code quality and checked with you on design questions would that be helpful? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Patch queue concern
Gregory Stark wrote: Obviously a big part of that is that we just don't have enough committers. I'm hopeful that in time that situation will improve but in the meantime we do have a problem and the burden falls unfairly on a few. Is there anything others can do to help? If non-committers like Simon or I reviewed patches would it be easier for you to give a quick agreement to the comments or that's not an issue comment? It seems like we do have a few committers who should be able to review code quality but are uncertain about making major design decisions. If, for example, Bruce or Jan reviewed patches more invasive than they usually do for code quality and checked with you on design questions would that be helpful? I try to review things that I feel are well within my area of competence (e.g plperl, sql level commands) but I feel more hesitant about things very deep inside the backend - there's more danger I'll miss something subtle there. Outside events have conspired to make both reviewing and coding harder for me to get done this cycle. As for major design decisions, these should not be in the hands of a reviewer anyway - they should be explicitly discussed on list. There is plenty of scope for people to review patches if they aren't committers. In fact, it is highly encouraged. Please review anything on the patch list you feel able to. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Patch queue concern
Andrew Dunstan [EMAIL PROTECTED] writes: There is plenty of scope for people to review patches if they aren't committers. In fact, it is highly encouraged. Please review anything on the patch list you feel able to. Sure. Even if you miss things, every problem you do spot is one less... and there's no guarantee that the eventual committer would have seen it. regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Patch queue concern
Gregory Stark wrote: Bruce Momjian [EMAIL PROTECTED] writes: It favours people who are short-sighted and don't see what possible improvements their code has. No code in an ongoing project like this is ever completed anyways. It favors those who do not wait until the last minute, but complete them well before the freeze date. What is this complete you keep talking about? Should I stop working on the sort/limit patch even though Heikki pointed out a few things to clean up and the cost model isn't updated yet just so that you'll consider it complete and put it on the patch queue? If I don't stop working on it you think we should just ignore it even if it's in a usable state now? Even the cost model changes could be done pretty easily with some guidance from a review. Complete means the author _thinks_ he is done, and has responded to all community comments on the patch. It's also an artifact of the working model we have where patches are sent in big chunks and reviewed much later during a feature freeze. If we were committing directly into a CVS repository we would have wanted to commit these changes as soon as they were ready for committing, not wait until they're completed. Then continue working and commit further changes. It's only This would have CVS containing uncomplete features --- and before beta, we would either have to beg the authors to complete them, or rip them out, neither of which we want to do. You don't want to commit something if it's in an unusable state and would have to be ripped out without more work. I said as soon as they're ready for committing as opposed to completed. You're asking people if they've stopped working on patches and you're surprised to find that there are a lot of patches people are still working on. That's silly, of course people are still working on them, many of these tasks are open ended and can be improved as long as we have time. just because they're still working on them doesn't necessarily mean what they have so far isn't worth committing as is yet. We don't want open-ended a few days before feature feeze. We want them to be as done, at some complete stopping point, and submitted. OK, but we don't want something that is ready to be committed, we need it complete. So how many more releases before you think Postgres is complete? I am getting tired of your semantic games, here, Greg. I have no idea what you are trying to accomplish, but I have better things to do. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Patch queue concern
We don't want open-ended a few days before feature feeze. We want them to be as done, at some complete stopping point, and submitted. OK, but we don't want something that is ready to be committed, we need it complete. So how many more releases before you think Postgres is complete? I am getting tired of your semantic games, here, Greg. I have no idea what you are trying to accomplish, but I have better things to do. I have to concur here. Everyone is doing the best that they can. Greg, how about reviewing some patches? Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Patch queue concern
Tom Lane wrote: Simon Riggs [EMAIL PROTECTED] writes: My feeling is we should have more regular sync points where the patch queue is emptied and everything committed or rejected. No doubt, but the real problem here is that reviewing/committing other people's patches is not fun, it's just work :-(. So it's no surprise that it tends to get put off. Not sure what to do about that. Of course, writing patches isn't totally _fun_ either. The big problem is shown in this chart: P a t c h C o m p l e x i t y Developer | Simple Complex -- Experienced | Easy Medium Novice | Medium Hard The basic problem is we have a lot of complex patches coming in, and many from people who do not have years of experience with submitting patches to PostgreSQL. A complex patch from a novice user takes a lot of time to review, and frankly, we don't have enough experienced developers doing such reviews. If the patch deals with an area of the code where I am not experienced, often even I am incapable of reviewing the patch. The bottom line is that we are getting more novice developers faster than we grow experienced developers. This is no big surprise, and I don't see a simple solution. Odds are this is going to continue. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Patch queue concern
Gregory Stark wrote: Tom Lane [EMAIL PROTECTED] writes: Simon Riggs [EMAIL PROTECTED] writes: My feeling is we should have more regular sync points where the patch queue is emptied and everything committed or rejected. No doubt, but the real problem here is that reviewing/committing other people's patches is not fun, it's just work :-(. So it's no surprise that it tends to get put off. Not sure what to do about that. Obviously a big part of that is that we just don't have enough committers. I'm hopeful that in time that situation will improve but in the meantime we do have a problem and the burden falls unfairly on a few. Is there anything others can do to help? If non-committers like Simon or I reviewed patches would it be easier for you to give a quick agreement to the comments or that's not an issue comment? Just to clarify, the committing is the easy part. I can do that all day and not break a sweat. It is making sure the patch is correct in all aspects --- functionality, clarity, modularity, reliability, design, etc. that takes lots of time, and really can be done by anyone in the community. We already have people commenting on other peoples patches, and new versions appearing, and every new version makes the final job of review/commit easier, because someone was going to have to make those changes before the patch was applied. It seems like we do have a few committers who should be able to review code quality but are uncertain about making major design decisions. If, for example, Bruce or Jan reviewed patches more invasive than they usually do for code quality and checked with you on design questions would that be helpful? I wish that would work, but the big trick is getting the entire problem into your head, matching user behavior with our existing code, and making those link up. There is really no _stage_ nature of final patch review. People can still comment on the patch, and improve it, but the final decision has to be a holistic one that makes sure the entire patch is in harmony. (I am sounding new-age here. :-) ) You might remember during I think 8.1 I started pushing patches because no one was objecting to the patches, and people complained because the patches we not complete. The patches had problems, but I was unable to fully understand some of the patches, and the patches had to be backed out. Since then, I haven't applied anything I didn't fully understand, so the patches not languish in the patch queue until an experienced PostgreSQL developer who does fully understand them can give me a green light on it. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Patch queue concern
Bruce Momjian wrote: OK, but we don't want something that is ready to be committed, we need it complete. So how many more releases before you think Postgres is complete? I am getting tired of your semantic games, here, Greg. I have no idea what you are trying to accomplish, but I have better things to do. Why not just post a specific list of the patches you are thinking of? Is it the patch queue list in total? Did I miss it? Without specifics these things just spiral on forever, as all debates about code do when there is no code to actually look at. With specifics it is self documenting and definitional. You are thinking / concerned about x patches. Folks can look at how to move them forward, and it would probably help guide community attention. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Patch queue concern
Bruce Momjian [EMAIL PROTECTED] writes: The basic problem is we have a lot of complex patches coming in, and many from people who do not have years of experience with submitting patches to PostgreSQL. A complex patch from a novice user takes a lot of time to review, and frankly, we don't have enough experienced developers doing such reviews. Part of the issue is that we have a lot of new developers who are trying to solve hard problems without having learned their way around the code by fixing easy stuff. It was easier some years ago for people to learn that way, because there was way more low-hanging fruit back then. But there's still some out there. I have a distinct sense that we are getting patches from people who are trying to run before they've learned to walk. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Patch queue concern
Hello, I found in queue patch simply custom variables protection, Pavel Stehule which you removed and didn't find my patch for scrollable cursors in plpgsql. Regards Pavel Stehule _ Emotikony a pozadi programu MSN Messenger ozivi vasi konverzaci. http://messenger.msn.cz/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Patch queue concern
Josh Berkus wrote: Bruce, However, with feature freeze coming on Sunday, I am worried because there are a significant number of patches that have are not ready for review because they have not been completed by their authors. Can you flag those somehow? I have sent out email on every one in the past few days, with the lists cc'ed. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Patch queue concern
Bruce Momjian [EMAIL PROTECTED] writes: Right now, all the patches I think are ready for review are in the patch queue: http://momjian.postgresql.org/cgi-bin/pgpatches However, with feature freeze coming on Sunday, I am worried because there are a significant number of patches that have are not ready for review because they have not been completed by their authors. That seems like a bit of a whacky criterion to use before reviewing a patch. It favours people who are short-sighted and don't see what possible improvements their code has. No code in an ongoing project like this is ever completed anyways. It's also an artifact of the working model we have where patches are sent in big chunks and reviewed much later during a feature freeze. If we were committing directly into a CVS repository we would have wanted to commit these changes as soon as they were ready for committing, not wait until they're completed. Then continue working and commit further changes. It's only because there's a two step process and the reviews are mainly happening during the feature freeze that there's any sense that some of them are completed. In fact they're not of course, there will be further changes in the same area once the freeze is lifted. I think you should be asking people whether they think the code is in a state where it can be committed, not whether they've finished working on it. Just because they see further work that can be done is no reason not to commit useful patches that are functional as they are. In fact Postgres historically has had an even looser standard. If the code is ready to be committed modulo bugs then it's been included in the feature freeze in the past. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Patch queue concern
On Tue, 2007-03-27 at 21:15 -0400, Bruce Momjian wrote: Right now, all the patches I think are ready for review are in the patch queue: http://momjian.postgresql.org/cgi-bin/pgpatches However, with feature freeze coming on Sunday, I am worried because there are a significant number of patches that have are not ready for review because they have not been completed by their authors. It's probably a good idea to have a queue of those too, to allow others to finish them if the original author hasn't/can't/won't. I'm not sure which ones you mean. I have at least 2 patches that depend upon other patches in the queue. I'm not sure how to go about completing them, so any advice or guidance would be welcome: - Scan_recycle_buffers depends upon synchronised scans because we agreed we would use the same parameter (if any exists) to govern the behaviour. Should I write a patch-on-patch? What happens if the patch changes after review? ISTM I should just wait until the first one is applied and then I can make the necessary changes in about an hour. The patch's main functionality is complete. - Fast cluster conflicts with Heikki's cluster patch, so one of them will need fixing depending which is applied first. I don't mind if its me going second. I also have proposed an additional mode on VACUUM FULL that builds upon Heikki's patch - should I submit that also, even though it cannot be applied? -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Patch queue concern
Gregory Stark wrote: Bruce Momjian [EMAIL PROTECTED] writes: Right now, all the patches I think are ready for review are in the patch queue: http://momjian.postgresql.org/cgi-bin/pgpatches However, with feature freeze coming on Sunday, I am worried because there are a significant number of patches that have are not ready for review because they have not been completed by their authors. That seems like a bit of a whacky criterion to use before reviewing a patch. wacky? It favours people who are short-sighted and don't see what possible improvements their code has. No code in an ongoing project like this is ever completed anyways. It favors those who do not wait until the last minute, but complete them well before the freeze date. It's also an artifact of the working model we have where patches are sent in big chunks and reviewed much later during a feature freeze. If we were committing directly into a CVS repository we would have wanted to commit these changes as soon as they were ready for committing, not wait until they're completed. Then continue working and commit further changes. It's only This would have CVS containing uncomplete features --- and before beta, we would either have to beg the authors to complete them, or rip them out, neither of which we want to do. because there's a two step process and the reviews are mainly happening during the feature freeze that there's any sense that some of them are completed. In fact they're not of course, there will be further changes in the same area once the freeze is lifted. I think you should be asking people whether they think the code is in a state where it can be committed, not whether they've finished working on it. Just because they see further work that can be done is no reason not to commit useful patches that are functional as they are. OK, but we don't want something that is ready to be committed, we need it complete. In fact Postgres historically has had an even looser standard. If the code is ready to be committed modulo bugs then it's been included in the feature freeze in the past. Well, if we know something has bugs, we fix them. Things are committed with bugs only because we don't know it has bugs when it was committed. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Patch queue concern
Simon Riggs wrote: On Tue, 2007-03-27 at 21:15 -0400, Bruce Momjian wrote: Right now, all the patches I think are ready for review are in the patch queue: http://momjian.postgresql.org/cgi-bin/pgpatches However, with feature freeze coming on Sunday, I am worried because there are a significant number of patches that have are not ready for review because they have not been completed by their authors. It's probably a good idea to have a queue of those too, to allow others to finish them if the original author hasn't/can't/won't. I'm not sure which ones you mean. At this point, with four days left before feature freeze, if the authors don't finish them, I doubt someone else is going to be able to do it. I have at least 2 patches that depend upon other patches in the queue. I'm not sure how to go about completing them, so any advice or guidance would be welcome: - Scan_recycle_buffers depends upon synchronised scans because we agreed we would use the same parameter (if any exists) to govern the behaviour. Should I write a patch-on-patch? What happens if the patch changes after review? ISTM I should just wait until the first one is applied and then I can make the necessary changes in about an hour. The patch's main functionality is complete. Yes, that is fine. I was unaware that is why the patch wasn't done. Once synchronised scans is in, I will go back to you and ask for a new version against CVS. I will put your email in the patch queue as a reminder. - Fast cluster conflicts with Heikki's cluster patch, so one of them will need fixing depending which is applied first. I don't mind if its me going second. I also have proposed an additional mode on VACUUM FULL that builds upon Heikki's patch - should I submit that also, even though it cannot be applied? OK, same rules. I am just glad that is all that was hold them up. I was worried. What about the delayed fsync patch? -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Patch queue concern
at seems like a bit of a whacky criterion to use before reviewing a patch. wacky? It favours people who are short-sighted and don't see what possible improvements their code has. No code in an ongoing project like this is ever completed anyways. It favors those who do not wait until the last minute, but complete them well before the freeze date. But wouldn't it hurt those that are continuously working the patch with the community? Just asking. It's also an artifact of the working model we have where patches are sent in big chunks and reviewed much later during a feature freeze. If we were committing directly into a CVS repository we would have wanted to commit these changes as soon as they were ready for committing, not wait until they're completed. Then continue working and commit further changes. It's only This would have CVS containing uncomplete features --- and before beta, we would either have to beg the authors to complete them, or rip them out, neither of which we want to do. I agree here. I think you should be asking people whether they think the code is in a state where it can be committed, not whether they've finished working on it. Just because they see further work that can be done is no reason not to commit useful patches that are functional as they are. OK, but we don't want something that is ready to be committed, we need it complete. Right, feature complete does not mean bug free that is what the testing period is for. In fact Postgres historically has had an even looser standard. If the code is ready to be committed modulo bugs then it's been included in the feature freeze in the past. Well, if we know something has bugs, we fix them. Things are committed with bugs only because we don't know it has bugs when it was committed. Yep :) Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Patch queue concern
Joshua D. Drake wrote: at seems like a bit of a whacky criterion to use before reviewing a patch. wacky? It favours people who are short-sighted and don't see what possible improvements their code has. No code in an ongoing project like this is ever completed anyways. It favors those who do not wait until the last minute, but complete them well before the freeze date. But wouldn't it hurt those that are continuously working the patch with the community? Just asking. Yea, it might, and it certainly hampers complex patches. I was caught up on the patch queue until the start of March, when I went on vacation, Tom started on cache invalidation, _and_ more complex patches started appearing. With those three, we had a perfect storm and the patch queue has gotten clogged, and I am afraid it isn't going to get unclogged until after feature freeze. I talked to Tom about this yesterday and he and I feel there isn't much we can do to change that, in the sense we are already doing the best we can, and clearing the remaining patches after feature freeze isn't that bad. One thing committers have to be willing to do is to give authors ample time after feature freeze to adjust patches after receiving feedback, because technically they should have received feedback _before_ feature freeze. Hopefully this will not significantly lengthen feature freeze. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Patch queue concern
On Wed, 2007-03-28 at 15:48 -0400, Bruce Momjian wrote: What about the delayed fsync patch? All complete bar two fiddly items, as of Mar 11, design-to-complete posted along with patch. Working on those now. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Patch queue concern
Bruce Momjian [EMAIL PROTECTED] writes: Simon Riggs wrote: It's probably a good idea to have a queue of those too, to allow others to finish them if the original author hasn't/can't/won't. I'm not sure which ones you mean. At this point, with four days left before feature freeze, if the authors don't finish them, I doubt someone else is going to be able to do it. This isn't the standard that we've used in the past. In the past patches that are mostly done and need some extra work done to polish them off are considered to have met the feature freeze. In any case I think Simon and you have fallen into the trap of thinking of development as a single-person project. Most developers here, especially first-time contributors, don't just work in the dark on their own and turn up with a finished patch. They have questions and need help in areas. If you insist on a finished patch before you even consider reviewing their work it's not going to work. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Patch queue concern
Gregory Stark wrote: Bruce Momjian [EMAIL PROTECTED] writes: Simon Riggs wrote: It's probably a good idea to have a queue of those too, to allow others to finish them if the original author hasn't/can't/won't. I'm not sure which ones you mean. At this point, with four days left before feature freeze, if the authors don't finish them, I doubt someone else is going to be able to do it. This isn't the standard that we've used in the past. In the past patches that are mostly done and need some extra work done to polish them off are considered to have met the feature freeze. My assumption is if authors don't finish them in the next few days, they are unlikely to finish them during some grace period during feature freeze. And the extra time is usually allowed for changes requested by committers, while at this point the authors aren't done and haven't even gotten to committer review. In any case I think Simon and you have fallen into the trap of thinking of development as a single-person project. Most developers here, especially first-time contributors, don't just work in the dark on their own and turn up with a finished patch. They have questions and need help in areas. If you insist on a finished patch before you even consider reviewing their work it's not going to work. Fine, if they need help, let them ask, but many authors are not asking for help --- they are just not completing the patches. Or they are going to surprise us by completing them on March 31. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Patch queue concern
On Wed, 2007-03-28 at 17:02 -0400, Bruce Momjian wrote: they It would be good to know who/what you're talking about, specifically. Some patchers may think they have completed their work. Not a name-and-shame, just fair warning their work is considered incomplete and is about to be rejected as a result. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Patch queue concern
Simon Riggs wrote: On Wed, 2007-03-28 at 17:02 -0400, Bruce Momjian wrote: they It would be good to know who/what you're talking about, specifically. Some patchers may think they have completed their work. Not a name-and-shame, just fair warning their work is considered incomplete and is about to be rejected as a result. Not sure how to do this without name-and-shame. I sent out emails to the list asking where we were on various open patches. I can do it again tomorrow so there is some context in the requests. Would that help? -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Patch queue concern
Bruce Momjian wrote: Gregory Stark wrote: Bruce Momjian [EMAIL PROTECTED] writes: Simon Riggs wrote: It's probably a good idea to have a queue of those too, to allow others to finish them if the original author hasn't/can't/won't. I'm not sure which ones you mean. At this point, with four days left before feature freeze, if the authors don't finish them, I doubt someone else is going to be able to do it. This isn't the standard that we've used in the past. In the past patches that are mostly done and need some extra work done to polish them off are considered to have met the feature freeze. My assumption is if authors don't finish them in the next few days, they are unlikely to finish them during some grace period during feature freeze. And the extra time is usually allowed for changes requested by committers, while at this point the authors aren't done and haven't even gotten to committer review. Well hold on Bruce, that isn't quite fair. I know there are patches in this cycle that have been waiting on reviewers/comitters not the other way around. Clustered indexes for example. I know that Gavin is this close to having vacuum finished for bitmap index on disk. Alvaro's vacuum patch isn't done either, although he has submitted WIP. Perhaps it makes sense to say: Feature Freeze: April 1st., no new patches accepted for 8.3 Patch Freeze April 15th., Authors have until the 15th to address any committer concerns ? Sincerely, Joshua D. Drake ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Patch queue concern
Joshua D. Drake wrote: My assumption is if authors don't finish them in the next few days, they are unlikely to finish them during some grace period during feature freeze. And the extra time is usually allowed for changes requested by committers, while at this point the authors aren't done and haven't even gotten to committer review. Well hold on Bruce, that isn't quite fair. I know there are patches in this cycle that have been waiting on reviewers/comitters not the other way around. Clustered indexes for example. I know that Gavin is this close to having vacuum finished for bitmap index on disk. Alvaro's vacuum patch isn't done either, although he has submitted WIP. Yes, for one, I am worried about bitmap indexes, and the performance testing time we are going to need to decide if we want it. In general, I am more concerned about patches where I don't see public patches/commit, like bitmap indexes, rather than patches like HOT that are being publicly advanced. All the patches might be advancing, but of course, I only see the public ones, and those are the only ones I can guess are near completion. I am speaking of my concerns now, rather than after feature freeze, because author options are more limited after feature freeze. Perhaps it makes sense to say: Feature Freeze: April 1st., no new patches accepted for 8.3 Patch Freeze April 15th., Authors have until the 15th to address any committer concerns Well, I am OK with that, but we need _community_ agreement on that. I realize it isn't fair that committers are behind on patches, while we are expecting submitters to make the deadline, but there are far fewer committers than submitters, and there was never a promise to commit everything before feature freeze. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Patch queue concern
Perhaps it makes sense to say: Feature Freeze: April 1st., no new patches accepted for 8.3 Patch Freeze April 15th., Authors have until the 15th to address any committer concerns Well, I am OK with that, but we need _community_ agreement on that. I realize it isn't fair that committers are behind on patches, while we are expecting submitters to make the deadline, but there are far fewer committers than submitters, and there was never a promise to commit everything before feature freeze. Yeah that was kind of my thinking is that everyone knows that the committers are behind (and overworked). So if we have this two week breather where it is all about patch review... Joshua D. Drake -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate PostgreSQL Replication: http://www.commandprompt.com/products/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Patch queue concern
On Wed, 2007-03-28 at 17:12 -0400, Bruce Momjian wrote: Simon Riggs wrote: On Wed, 2007-03-28 at 17:02 -0400, Bruce Momjian wrote: they It would be good to know who/what you're talking about, specifically. Some patchers may think they have completed their work. Not a name-and-shame, just fair warning their work is considered incomplete and is about to be rejected as a result. Not sure how to do this without name-and-shame. I sent out emails to the list asking where we were on various open patches. I can do it again tomorrow so there is some context in the requests. Would that help? Please publish the list. I'm sure it will raise eyebrows, but we can sort out any misunderstandings; there's no shame in attempting something and meeting a blockage - thats normal. If everybody knows where everybody stands then we'll all be better off. There may be other dependencies that need resolution, or last minute decisions required to allow authors to finish. Plus I want to check whether I'm on it, or not. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Patch queue concern
On Wed, 28 Mar 2007, Simon Riggs wrote: On Wed, 2007-03-28 at 17:12 -0400, Bruce Momjian wrote: If everybody knows where everybody stands then we'll all be better off. There may be other dependencies that need resolution, or last minute decisions required to allow authors to finish. Wasn't this the purpose of the wiki page that was set up? I notice it has not been updated in a while... http://developer.postgresql.org/index.php/Todo:WishlistFor83 -- If the aborigine drafted an IQ test, all of Western civilization would presumably flunk it. -- Stanley Garn ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Patch queue concern
On Wed, 2007-03-28 at 17:37 -0400, Bruce Momjian wrote: I realize it isn't fair that committers are behind on patches, while we are expecting submitters to make the deadline, but there are far fewer committers than submitters, and there was never a promise to commit everything before feature freeze. I'm expecting to review patches after freeze and I'm much more free to do that now than I have been previously. It seems important we have a tiered review process so that some of the more obvious flaws can be driven out of patches as early as possible. If we can set expectations that every developer has to contribute review time, committer or not, then we'll all be better off. That need not take away authority from committers, nor give it to reviewers. Anybody and everybody is certainly welcome to comment on my own patches. My feeling is we should have more regular sync points where the patch queue is emptied and everything committed or rejected. That way rejection is less of a problem and we will all have more opportunity to build upon each others good work. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Patch queue concern
Bruce Momjian [EMAIL PROTECTED] writes: It favours people who are short-sighted and don't see what possible improvements their code has. No code in an ongoing project like this is ever completed anyways. It favors those who do not wait until the last minute, but complete them well before the freeze date. What is this complete you keep talking about? Should I stop working on the sort/limit patch even though Heikki pointed out a few things to clean up and the cost model isn't updated yet just so that you'll consider it complete and put it on the patch queue? If I don't stop working on it you think we should just ignore it even if it's in a usable state now? Even the cost model changes could be done pretty easily with some guidance from a review. It's also an artifact of the working model we have where patches are sent in big chunks and reviewed much later during a feature freeze. If we were committing directly into a CVS repository we would have wanted to commit these changes as soon as they were ready for committing, not wait until they're completed. Then continue working and commit further changes. It's only This would have CVS containing uncomplete features --- and before beta, we would either have to beg the authors to complete them, or rip them out, neither of which we want to do. You don't want to commit something if it's in an unusable state and would have to be ripped out without more work. I said as soon as they're ready for committing as opposed to completed. You're asking people if they've stopped working on patches and you're surprised to find that there are a lot of patches people are still working on. That's silly, of course people are still working on them, many of these tasks are open ended and can be improved as long as we have time. just because they're still working on them doesn't necessarily mean what they have so far isn't worth committing as is yet. OK, but we don't want something that is ready to be committed, we need it complete. So how many more releases before you think Postgres is complete? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Patch queue concern
Gregory Stark wrote: Bruce Momjian [EMAIL PROTECTED] writes: That's silly, of course people are still working on them, many of these tasks are open ended and can be improved as long as we have time. just because they're still working on them doesn't necessarily mean what they have so far isn't worth committing as is yet. OK, but we don't want something that is ready to be committed, we need it complete. So how many more releases before you think Postgres is complete? You are using the word complete as in final and unalterable. That's not, it seems to me, what Bruce means. Bruce has a point, and a valid and sensible one at that. A patch that is ready to be committed does not mean it is usable. Just because you can commit a patch does not mean that the patch will be useful. Well, if a patch author has promised to supply a patch for the X function, and has not completed a stable and generally usable patch for X, then the patch is not worth committing. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Patch queue concern
Gregory Stark wrote: In any case I think Simon and you have fallen into the trap of thinking of development as a single-person project. Most developers here, especially first-time contributors, don't just work in the dark on their own and turn up with a finished patch. They have questions and need help in areas. If you insist on a finished patch before you even consider reviewing their work it's not going to work. This isn't about finished patches. It's about commit-worthy patches, and since the term is very subjective, there has to be some way for an arbiter to be able to say that such a patch is worth committing. And I think the arbiter should not come from any of the two opposing sides with diametrically opposed claims or opinions. Thank you very much. Best Regards, Carlo -- Carlo Florendo Softare Engineer/Network Co-Administrator Astra Philippines Inc. UP-Ayala Technopark, Diliman 1101, Quezon City Philippines http://www.astra.ph -- The Astra Group of Companies 5-3-11 Sekido, Tama City Tokyo 206-0011, Japan http://www.astra.co.jp ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Patch queue concern
Simon Riggs [EMAIL PROTECTED] writes: My feeling is we should have more regular sync points where the patch queue is emptied and everything committed or rejected. No doubt, but the real problem here is that reviewing/committing other people's patches is not fun, it's just work :-(. So it's no surprise that it tends to get put off. Not sure what to do about that. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
[HACKERS] Patch queue concern
Right now, all the patches I think are ready for review are in the patch queue: http://momjian.postgresql.org/cgi-bin/pgpatches However, with feature freeze coming on Sunday, I am worried because there are a significant number of patches that have are not ready for review because they have not been completed by their authors. -- Bruce Momjian [EMAIL PROTECTED] http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] Patch queue concern
Bruce, However, with feature freeze coming on Sunday, I am worried because there are a significant number of patches that have are not ready for review because they have not been completed by their authors. Can you flag those somehow? -- Josh Berkus PostgreSQL @ Sun San Francisco ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Patch queue
On 1/30/07, Bruce Momjian [EMAIL PROTECTED] wrote: FYI, I have been working all January to process 8.3 held patches/ideas, plus process the items arriving during the month. While I have been able to make some progress, there are still a significant number of items for me to address. I will keep working on it and try to complete it by mid-February. i think this does not belong to any queue ;) http://momjian.us/mhonarc/patches/msg6.html at http://momjian.postgresql.org/cgi-bin/pgpatches -- regards, Jaime Casanova Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning. Richard Cook ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Patch queue
Jaime Casanova wrote: On 1/30/07, Bruce Momjian [EMAIL PROTECTED] wrote: FYI, I have been working all January to process 8.3 held patches/ideas, plus process the items arriving during the month. While I have been able to make some progress, there are still a significant number of items for me to address. I will keep working on it and try to complete it by mid-February. i think this does not belong to any queue ;) http://momjian.us/mhonarc/patches/msg6.html at http://momjian.postgresql.org/cgi-bin/pgpatches Wow, good one. I was keeping that for posterity, and put it in the wrong file. Thanks. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
