Обсуждение: Lack of urgency in 8.3 reviewing
In talking to people who are assigned to review patches or could review patches, I often get the reply, "Oh, yea, I need to do that". Folks, we are six weeks into feature freeze and have made slim progress on getting patches reviewed and applied. As I stated earlier, we are now looking at August/September for beta, but that might be pushed back even later if we don't get more progress. It seems there is a lot of reliance on Tom to get the patches applied, but I don't think that is fair or reasonable. I think we need more urgency on the part of everyone to make faster progress. Patch reviewers and committers need to take more initiative to get things done rather than wait for some external force to prompt them. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > In talking to people who are assigned to review patches or could review > patches, I often get the reply, "Oh, yea, I need to do that". > > It seems there is a lot of reliance on Tom to get the patches applied, > but I don't think that is fair or reasonable. I think we need more > urgency on the part of everyone to make faster progress. Patch > reviewers and committers need to take more initiative to get things done > rather than wait for some external force to prompt them. We have *alot* of people (comparatively) who can assist in reviewing code that are not committers. Even if they can not commit, they can help insure that patches are in a state that can be more easily reviewed for committers to actually test and apply. Joshua D. Drake >
Bruce, where can I take a look at the patch list in order to find out if I can be of some help? Regards, g.- On 5/16/07, Bruce Momjian <bruce@momjian.us> wrote: > In talking to people who are assigned to review patches or could review > patches, I often get the reply, "Oh, yea, I need to do that". > > Folks, we are six weeks into feature freeze and have made slim progress > on getting patches reviewed and applied. As I stated earlier, we are > now looking at August/September for beta, but that might be pushed back > even later if we don't get more progress. > > It seems there is a lot of reliance on Tom to get the patches applied, > but I don't think that is fair or reasonable. I think we need more > urgency on the part of everyone to make faster progress. Patch > reviewers and committers need to take more initiative to get things done > rather than wait for some external force to prompt them. > > -- > Bruce Momjian <bruce@momjian.us> 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 > -- Guido Barosio ----------------------- http://www.globant.com guido.barosio@globant.com
It is all on the developer roadmap page: http://momjian.us/cgi-bin/pgpatches --------------------------------------------------------------------------- Guido Barosio wrote: > Bruce, where can I take a look at the patch list in order to find out > if I can be of some help? > > Regards, > g.- > > On 5/16/07, Bruce Momjian <bruce@momjian.us> wrote: > > In talking to people who are assigned to review patches or could review > > patches, I often get the reply, "Oh, yea, I need to do that". > > > > Folks, we are six weeks into feature freeze and have made slim progress > > on getting patches reviewed and applied. As I stated earlier, we are > > now looking at August/September for beta, but that might be pushed back > > even later if we don't get more progress. > > > > It seems there is a lot of reliance on Tom to get the patches applied, > > but I don't think that is fair or reasonable. I think we need more > > urgency on the part of everyone to make faster progress. Patch > > reviewers and committers need to take more initiative to get things done > > rather than wait for some external force to prompt them. > > > > -- > > Bruce Momjian <bruce@momjian.us> 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 > > > > > -- > Guido Barosio > ----------------------- > http://www.globant.com > guido.barosio@globant.com -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Bruce Momjian wrote: > It is all on the developer roadmap page: > > http://momjian.us/cgi-bin/pgpatches > There is also a slightly more readable one here: http://developer.postgresql.org/index.php/Todo:PatchStatus Joshua D. Drake > --------------------------------------------------------------------------- > > Guido Barosio wrote: >> Bruce, where can I take a look at the patch list in order to find out >> if I can be of some help? >> >> Regards, >> g.- >> >> On 5/16/07, Bruce Momjian <bruce@momjian.us> wrote: >>> In talking to people who are assigned to review patches or could review >>> patches, I often get the reply, "Oh, yea, I need to do that". >>> >>> Folks, we are six weeks into feature freeze and have made slim progress >>> on getting patches reviewed and applied. As I stated earlier, we are >>> now looking at August/September for beta, but that might be pushed back >>> even later if we don't get more progress. >>> >>> It seems there is a lot of reliance on Tom to get the patches applied, >>> but I don't think that is fair or reasonable. I think we need more >>> urgency on the part of everyone to make faster progress. Patch >>> reviewers and committers need to take more initiative to get things done >>> rather than wait for some external force to prompt them. >>> >>> -- >>> Bruce Momjian <bruce@momjian.us> 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 >>> >> >> -- >> Guido Barosio >> ----------------------- >> http://www.globant.com >> guido.barosio@globant.com >
Bruce Momjian wrote: > In talking to people who are assigned to review patches or could review > patches, I often get the reply, "Oh, yea, I need to do that". > > Folks, we are six weeks into feature freeze and have made slim progress > on getting patches reviewed and applied. As I stated earlier, we are > now looking at August/September for beta, but that might be pushed back > even later if we don't get more progress. > > It seems there is a lot of reliance on Tom to get the patches applied, > but I don't think that is fair or reasonable. I think we need more > urgency on the part of everyone to make faster progress. Patch > reviewers and committers need to take more initiative to get things done > rather than wait for some external force to prompt them. > > I at least feel uncomfortable about reviewing code that deals with areas I have not touched much, and where I feel the author probably knows a lot more than me. The chance of my catching errors/problems in such a case is much lower. Looking at the list on the wiki, that rules out most of the things that don't have a reviewer already listed. I can look at the following items: . UTF8 text matching performance improvements . concurrent psql . PL/PSM If Tom gets around to per-function search paths I'll look at that too, but I don't actually recall seeing a patch for that. cheers andrew
Joshua D. Drake wrote: > Bruce Momjian wrote: >> It is all on the developer roadmap page: >> >> http://momjian.us/cgi-bin/pgpatches >> > > There is also a slightly more readable one here: > > http://developer.postgresql.org/index.php/Todo:PatchStatus note that http://momjian.us/cgi-bin/pgpatches contains a link to the wiki site at the very top ;-) Stefan
Andrew Dunstan wrote: > > > Bruce Momjian wrote: > > In talking to people who are assigned to review patches or could review > > patches, I often get the reply, "Oh, yea, I need to do that". > > > > Folks, we are six weeks into feature freeze and have made slim progress > > on getting patches reviewed and applied. As I stated earlier, we are > > now looking at August/September for beta, but that might be pushed back > > even later if we don't get more progress. > > > > It seems there is a lot of reliance on Tom to get the patches applied, > > but I don't think that is fair or reasonable. I think we need more > > urgency on the part of everyone to make faster progress. Patch > > reviewers and committers need to take more initiative to get things done > > rather than wait for some external force to prompt them. > > > > > > I at least feel uncomfortable about reviewing code that deals with areas > I have not touched much, and where I feel the author probably knows a > lot more than me. The chance of my catching errors/problems in such a > case is much lower. Yep, that is part of our problem, but even items people have already said they _can_ review have shown little progress. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Andrew Dunstan wrote: > > > Bruce Momjian wrote: >> In talking to people who are assigned to review patches or could review >> patches, I often get the reply, "Oh, yea, I need to do that". >> >> Folks, we are six weeks into feature freeze and have made slim progress >> on getting patches reviewed and applied. As I stated earlier, we are >> now looking at August/September for beta, but that might be pushed back >> even later if we don't get more progress. >> >> It seems there is a lot of reliance on Tom to get the patches applied, >> but I don't think that is fair or reasonable. I think we need more >> urgency on the part of everyone to make faster progress. Patch >> reviewers and committers need to take more initiative to get things done >> rather than wait for some external force to prompt them. >> >> > > I at least feel uncomfortable about reviewing code that deals with areas > I have not touched much, and where I feel the author probably knows a > lot more than me. The chance of my catching errors/problems in such a > case is much lower. > > Looking at the list on the wiki, that rules out most of the things that > don't have a reviewer already listed. I can look at the following items: > > . UTF8 text matching performance improvements > . concurrent psql > . PL/PSM added your name to the list in the wiki > > If Tom gets around to per-function search paths I'll look at that too, > but I don't actually recall seeing a patch for that. no - tom said in is patch triage mail that this code is not even written yet but he still wants to see it in 8.3 ... Stefan
What about a mentoring schema in order to push up the gap that represents catching up with cases like the one Andrew posted? By the way, being a patch reviewer doesn't represents also to be able to find out potential problems in the code, which may have nothing to do with the patch functionality? g.- On 5/16/07, Bruce Momjian <bruce@momjian.us> wrote: > Andrew Dunstan wrote: > > > > > > Bruce Momjian wrote: > > > In talking to people who are assigned to review patches or could review > > > patches, I often get the reply, "Oh, yea, I need to do that". > > > > > > Folks, we are six weeks into feature freeze and have made slim progress > > > on getting patches reviewed and applied. As I stated earlier, we are > > > now looking at August/September for beta, but that might be pushed back > > > even later if we don't get more progress. > > > > > > It seems there is a lot of reliance on Tom to get the patches applied, > > > but I don't think that is fair or reasonable. I think we need more > > > urgency on the part of everyone to make faster progress. Patch > > > reviewers and committers need to take more initiative to get things done > > > rather than wait for some external force to prompt them. > > > > > > > > > > I at least feel uncomfortable about reviewing code that deals with areas > > I have not touched much, and where I feel the author probably knows a > > lot more than me. The chance of my catching errors/problems in such a > > case is much lower. > > Yep, that is part of our problem, but even items people have already > said they _can_ review have shown little progress. > > -- > Bruce Momjian <bruce@momjian.us> 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 > -- Guido Barosio ----------------------- http://www.globant.com guido.barosio@globant.com
I think one of the things that is preventing urgency is that everyone knows we have large patches unapplied, so they know that their lack of activity is not holding up the release. Any way around that? --------------------------------------------------------------------------- bruce wrote: > In talking to people who are assigned to review patches or could review > patches, I often get the reply, "Oh, yea, I need to do that". > > Folks, we are six weeks into feature freeze and have made slim progress > on getting patches reviewed and applied. As I stated earlier, we are > now looking at August/September for beta, but that might be pushed back > even later if we don't get more progress. > > It seems there is a lot of reliance on Tom to get the patches applied, > but I don't think that is fair or reasonable. I think we need more > urgency on the part of everyone to make faster progress. Patch > reviewers and committers need to take more initiative to get things done > rather than wait for some external force to prompt them. > > -- > Bruce Momjian <bruce@momjian.us> http://momjian.us > EnterpriseDB http://www.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Wednesday, May 16, 2007 20:09:44 -0400 Bruce Momjian <bruce@momjian.us> wrote: > > I think one of the things that is preventing urgency is that everyone > knows we have large patches unapplied, so they know that their lack of > activity is not holding up the release. Any way around that? Set a fixed date (ie. 3 weeks) and whatever isn't in gets punted to 8.4 ... if that means those 'large patches' don't get applied, so be it ... > > --------------------------------------------------------------------------- > > bruce wrote: >> In talking to people who are assigned to review patches or could review >> patches, I often get the reply, "Oh, yea, I need to do that". >> >> Folks, we are six weeks into feature freeze and have made slim progress >> on getting patches reviewed and applied. As I stated earlier, we are >> now looking at August/September for beta, but that might be pushed back >> even later if we don't get more progress. >> >> It seems there is a lot of reliance on Tom to get the patches applied, >> but I don't think that is fair or reasonable. I think we need more >> urgency on the part of everyone to make faster progress. Patch >> reviewers and committers need to take more initiative to get things done >> rather than wait for some external force to prompt them. >> >> -- >> Bruce Momjian <bruce@momjian.us> http://momjian.us >> EnterpriseDB http://www.enterprisedb.com >> >> + If your life is a hard drive, Christ can be your backup. + > > -- > Bruce Momjian <bruce@momjian.us> 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 - ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGS6Oa4QvfyHIvDvMRAtwrAJwLasoe+jiuAqvT4Dny/dndYvKxUgCcDxiX x+vMZlGMy06D9NOfzltG/ks= =PL+8 -----END PGP SIGNATURE-----
On 5/16/07, Marc G. Fournier <scrappy@hub.org> wrote: > Set a fixed date (ie. 3 weeks) and whatever isn't in gets punted to 8.4 ... if > that means those 'large patches' don't get applied, so be it ... I disagree with that approach. Larger more complex patches required much more work and effort than small, simple ones. Not only do I think it's unfair to the authors who spent considerably more time on their work, but I think it also sets a bad precedent for future work; saying, in short, that if you want to make large strides to improve PostgreSQL, and you followed the community development process, you're still potentially last in line for review. -- Jonah H. Harris, Software Architect | phone: 732.331.1324 EnterpriseDB Corporation | fax: 732.331.1301 33 Wood Ave S, 3rd Floor | jharris@enterprisedb.com Iselin, New Jersey 08830 | http://www.enterprisedb.com/
Jonah H. Harris wrote: > On 5/16/07, Marc G. Fournier <scrappy@hub.org> wrote: > > Set a fixed date (ie. 3 weeks) and whatever isn't in gets punted to 8.4 ... if > > that means those 'large patches' don't get applied, so be it ... > > I disagree with that approach. Larger more complex patches required > much more work and effort than small, simple ones. Not only do I > think it's unfair to the authors who spent considerably more time on > their work, but I think it also sets a bad precedent for future work; > saying, in short, that if you want to make large strides to improve > PostgreSQL, and you followed the community development process, you're > still potentially last in line for review. Yep. We lose a lot of credibility if we did that. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - --On Wednesday, May 16, 2007 21:04:27 -0400 Bruce Momjian <bruce@momjian.us> wrote: > Jonah H. Harris wrote: >> On 5/16/07, Marc G. Fournier <scrappy@hub.org> wrote: >> > Set a fixed date (ie. 3 weeks) and whatever isn't in gets punted to 8.4 >> > ... if that means those 'large patches' don't get applied, so be it ... >> >> I disagree with that approach. Larger more complex patches required >> much more work and effort than small, simple ones. Not only do I >> think it's unfair to the authors who spent considerably more time on >> their work, but I think it also sets a bad precedent for future work; >> saying, in short, that if you want to make large strides to improve >> PostgreSQL, and you followed the community development process, you're >> still potentially last in line for review. > > Yep. We lose a lot of credibility if we did that. So, we lose no credibility if we sit in feature freeze indefinitely, with no direction, while we wait for reviewers to finish reviewing? - ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . scrappy@hub.org MSN . scrappy@hub.org Yahoo . yscrappy Skype: hub.org ICQ . 7615664 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFGS7E64QvfyHIvDvMRAmW9AJ0Q75300Atm6nFOFT+1YfMRCtrcdQCffW2l htlQKO5dZRC2k2lWPGkjGvk= =BhsF -----END PGP SIGNATURE-----
Marc G. Fournier wrote: > > Jonah H. Harris wrote: > >> On 5/16/07, Marc G. Fournier <scrappy@hub.org> wrote: > >> > Set a fixed date (ie. 3 weeks) and whatever isn't in gets punted to 8.4 > >> > ... if that means those 'large patches' don't get applied, so be it ... > >> > >> I disagree with that approach. Larger more complex patches required > >> much more work and effort than small, simple ones. Not only do I > >> think it's unfair to the authors who spent considerably more time on > >> their work, but I think it also sets a bad precedent for future work; > >> saying, in short, that if you want to make large strides to improve > >> PostgreSQL, and you followed the community development process, you're > >> still potentially last in line for review. > > > > Yep. We lose a lot of credibility if we did that. > > So, we lose no credibility if we sit in feature freeze indefinitely, with no > direction, while we wait for reviewers to finish reviewing? Well, if we stay indefinitely, then we have no release and we close up the project. I think eventually we will release. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
Marc G. Fournier wrote:
>>> I disagree with that approach. Larger more complex patches required
>>> much more work and effort than small, simple ones. Not only do I
>>> think it's unfair to the authors who spent considerably more time on
>>> their work, but I think it also sets a bad precedent for future work;
>>> saying, in short, that if you want to make large strides to improve
>>> PostgreSQL, and you followed the community development process, you're
>>> still potentially last in line for review.
>> Yep. We lose a lot of credibility if we did that.
>
> So, we lose no credibility if we sit in feature freeze indefinitely, with no
> direction, while we wait for reviewers to finish reviewing?
*cough* that is hardly what is happening. Just today we had two people
step up and commit to help reviewing. One of them is a committer (AndrewD).
I believe under no uncertain terms, that if we continual proactive
communication over the next several weeks that we will see a marked and
steady improvement to our existing status.
Let's keep this on earth shall we.
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/
On 5/16/07, Bruce Momjian <bruce@momjian.us> wrote:
Yep, that is part of our problem, but even items people have already
said they _can_ review have shown little progress.
For complex patches, it might help to identify and associate a core/senior
community member in the early stages of design and development. This
member will then have enough insight into the work as it progresses and can
him/herself act as a committer and/or help the committer later.
We developed HOT in a phased manner. Had each of the incremental patches
been reviewed, I think the review process would have been much easier
and less painful. Also that would have helped us to identify any obvious
bugs/show stoppers early in the cycle and might have even generated better
ideas to do things differently.
Having said that, I fully understand the difficulties of the committers who
need to put substantial efforts in understanding the patch and guage its
overall impact.
Thanks,
Pavan
--
EnterpriseDB http://www.enterprisedb.com
Marc G. Fournier wrote: > > > --On Wednesday, May 16, 2007 20:09:44 -0400 Bruce Momjian <bruce@momjian.us> > wrote: > >> I think one of the things that is preventing urgency is that everyone >> knows we have large patches unapplied, so they know that their lack of >> activity is not holding up the release. Any way around that? > > Set a fixed date (ie. 3 weeks) and whatever isn't in gets punted to 8.4 ... if > that means those 'large patches' don't get applied, so be it ... Meaning we lose a bunch of potentially very cool features, and seriously hack off the developers who put significant time and effort into them, in some cases producing numerous updates based on ongoing discussion and feedback over a number of months. And then in 8.4 we have the same problem... I think we just have to accept that we're gonna have a long feature freeze period, and ask people to help review whatever they can. Regards, Dave.
I want to help the reviewing work of "ctid chain following enhancement ". I've been studying the souce code which related with that part recently. :-) 2007/5/17, Dave Page <dpage@postgresql.org>: > I think we just have to accept that we're gonna have a long feature > freeze period, and ask people to help review whatever they can. > > Regards, Dave. > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend >
Cui Shijun wrote: > I want to help the reviewing work of "ctid chain following enhancement ". > I've been studying the souce code which related with that part recently. > :-) Please go ahead :-) Regards Dave
On 5/17/07, Cui Shijun <rancpine@gmail.com> wrote:
Tom had objected to this patch on the grounds that it adds complexity
without any significant gains. Though I don't completely agree with the
first part, the second part is indeed debatable since the code is touched only
for infrequently.
Thanks,
Pavan
I want to help the reviewing work of "ctid chain following enhancement ".
I've been studying the souce code which related with that part recently.
:-)
Tom had objected to this patch on the grounds that it adds complexity
without any significant gains. Though I don't completely agree with the
first part, the second part is indeed debatable since the code is touched only
for infrequently.
Pavan
--
EnterpriseDB http://www.enterprisedb.com
Pavan Deolasee wrote: > On 5/17/07, Cui Shijun <rancpine@gmail.com> wrote: > > > > I want to help the reviewing work of "ctid chain following enhancement ". > > I've been studying the souce code which related with that part recently. > > :-) > > > > Tom had objected to this patch on the grounds that it adds complexity > without any significant gains. Though I don't completely agree with the > first part, the second part is indeed debatable since the code is touched > only > for infrequently. Right. The reason the patch was kept in the queue is that there was discussion that HOT will exercise that part of the code a lot more than it does currently. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
I see... I checked part of HOT patches(patch1), and found that it involves too many things I am not currently familar with. Maybe I should change an item to work. :-( Since I only studied part of source codes about transaction processing(lmgr/MVCC/xact but without xlog.c), I want to study "Group Commit" patch and try to review it, any suggestions? 2007/5/17, Bruce Momjian <bruce@momjian.us>: > Pavan Deolasee wrote: > > On 5/17/07, Cui Shijun <rancpine@gmail.com> wrote: > > > > > > I want to help the reviewing work of "ctid chain following enhancement ". > > > I've been studying the souce code which related with that part recently. > > > :-) > > > > > > > > Tom had objected to this patch on the grounds that it adds complexity > > without any significant gains. Though I don't completely agree with the > > first part, the second part is indeed debatable since the code is touched > > only > > for infrequently. > > Right. The reason the patch was kept in the queue is that there was > discussion that HOT will exercise that part of the code a lot more than > it does currently. > > -- > Bruce Momjian <bruce@momjian.us> http://momjian.us > EnterpriseDB http://www.enterprisedb.com > > + If your life is a hard drive, Christ can be your backup. + >
Cui Shijun wrote: > I see... > I checked part of HOT patches(patch1), and found that it involves too > many things I am not currently familar with. Maybe I should change an > item to work. :-( Yeah, that's one big patch.. > Since I only studied part of source codes about transaction > processing(lmgr/MVCC/xact but without xlog.c), I want to study > "Group Commit" patch and try to review it, any suggestions? There's no group commit patch, just some discussion, and probably won't be until 8.4. Maybe one of these would interest you: - deferred transaction/waitless COMMIT - full page writes improvement - maintaining cluster order on insert - heap page diagnostic functions Make sure you look at the latest version of the patches. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Thank you for your suggestions, I am thinking about "Full page writes improvement". It seems not so complicated, just fit for a novice like me. I'll work on it. :-) 2007/5/17, Heikki Linnakangas <heikki@enterprisedb.com>: > Cui Shijun wrote: > > I see... > > I checked part of HOT patches(patch1), and found that it involves too > > many things I am not currently familar with. Maybe I should change an > > item to work. :-( > > Yeah, that's one big patch.. > > > Since I only studied part of source codes about transaction > > processing(lmgr/MVCC/xact but without xlog.c), I want to study > > "Group Commit" patch and try to review it, any suggestions? > > There's no group commit patch, just some discussion, and probably won't > be until 8.4. > > Maybe one of these would interest you: > - deferred transaction/waitless COMMIT > - full page writes improvement > - maintaining cluster order on insert > - heap page diagnostic functions > > Make sure you look at the latest version of the patches. > > -- > Heikki Linnakangas > EnterpriseDB http://www.enterprisedb.com >
Heikki Linnakangas wrote:
> - heap page diagnostic functions
I would like to take this review (after PGCon).
Zdenek
Zdenek Kotala wrote: > Heikki Linnakangas wrote: > >> - heap page diagnostic functions > > I would like to take this review (after PGCon). Too late, Bruce applied it already :). More eyeballs on it still wouldn't hurt of course. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
Heikki Linnakangas wrote:
> Zdenek Kotala wrote:
>> Heikki Linnakangas wrote:
>>
>>> - heap page diagnostic functions
>>
>> I would like to take this review (after PGCon).
>
> Too late, Bruce applied it already :).
Yes ... Never mind
What's about
- full page writes improvement
but I will have time after PGCon.
Zdenek
Zdenek Kotala wrote: > Heikki Linnakangas wrote: > >Zdenek Kotala wrote: > >>Heikki Linnakangas wrote: > >> > >>>- heap page diagnostic functions > >> > >>I would like to take this review (after PGCon). > > > >Too late, Bruce applied it already :). > > Yes ... Never mind You know, the fact that it was applied does not mean that it doesn't need review. If there is a bug on it which your review can find, we would like to know before it is released. The review process is not just so that it can be flown past some evil committee. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote: > Zdenek Kotala wrote: > > Heikki Linnakangas wrote: > > >Zdenek Kotala wrote: > > >>Heikki Linnakangas wrote: > > >> > > >>>- heap page diagnostic functions > > >> > > >>I would like to take this review (after PGCon). > > > > > >Too late, Bruce applied it already :). > > > > Yes ... Never mind > > You know, the fact that it was applied does not mean that it doesn't > need review. If there is a bug on it which your review can find, we > would like to know before it is released. > > The review process is not just so that it can be flown past some evil > committee. I forgot to add that it seems that a general feeling here is that as soon as code is committed, it is Tom Lane's problem if there is a bug, because he will track it down and fix it. So if it was committed, we can forget about it because he'll take care. -- Alvaro Herrera http://www.PlanetPostgreSQL.org/ "Granting software the freedom to evolve guarantees only different results, not better ones." (Zygo Blaxell)
Alvaro Herrera wrote: > Alvaro Herrera wrote: >> Zdenek Kotala wrote: >>> Heikki Linnakangas wrote: >>>> Zdenek Kotala wrote: >>>>> Heikki Linnakangas wrote: >>>>> >>>>>> - heap page diagnostic functions >>>>> I would like to take this review (after PGCon). >>>> Too late, Bruce applied it already :). >>> Yes ... Never mind >> You know, the fact that it was applied does not mean that it doesn't >> need review. If there is a bug on it which your review can find, we >> would like to know before it is released. >> >> The review process is not just so that it can be flown past some evil >> committee. > > I forgot to add that it seems that a general feeling here is that as > soon as code is committed, it is Tom Lane's problem if there is a bug, > because he will track it down and fix it. So if it was committed, we > can forget about it because he'll take care. I hope that's not how people think. I try to track down bugs when they're reported when they're in areas of code that I'm familiar with, but Tom still usually beats me to it. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
On Fri, May 18, 2007 at 12:33:11AM +0800, Cui Shijun wrote: > Thank you for your suggestions, I am thinking about "Full page writes > improvement". It seems not so complicated, just fit for a novice like > me. > I'll work on it. :-) Updated on http://developer.postgresql.org/index.php/Todo:PatchStatus -- Jim Nasby decibel@decibel.org EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
On Fri, May 18, 2007 at 03:21:00PM +0200, Zdenek Kotala wrote: > What's about > > - full page writes improvement > > but I will have time after PGCon. Added you to the list for that at http://developer.postgresql.org/index.php/Todo:PatchStatus -- Jim Nasby decibel@decibel.org EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
Bruce Momjian wrote: > In talking to people who are assigned to review patches or could review > patches, I often get the reply, "Oh, yea, I need to do that". Would it inspire more people to learn enough to become patch reviewers if patch authors scheduled walkthroughs of their patches with question and answer sessions over IRC or maybe even some voice conferencing system like skype? While it might not be of immediate value, I imagine a number of inspiring-to-be-hackers might find such walkthroughs enlightening, and if actual qualified reviewers participate in the Q&A during those walkthroughs seeing the kinds of questions raised would be quite educational as well. I don't know if this would help - I guess it needs 3 things: patch authors willing to do such walkthroughs, qualified people willing to participate in them, and enough wannabe hackers wanting to listen in. Do people think this would help- or is it just a clunkier way of doing what's already done via email on the patches list?
Ron Mayer wrote: > Bruce Momjian wrote: >> In talking to people who are assigned to review patches or could review >> patches, I often get the reply, "Oh, yea, I need to do that". > > Would it inspire more people to learn enough to become patch > reviewers if patch authors scheduled walkthroughs of their > patches with question and answer sessions over IRC or maybe > even some voice conferencing system like skype? It is common in one company but I'm not sure if it is possible do in open source community. I think the following tool looks likes good solution for patch review: http://www.chipx86.com/blog/?p=222 http://code.google.com/p/reviewboard/ Zdenek