Re: [HACKERS] Commitfest status
On 09/20/2014 06:54 AM, Michael Paquier wrote: CF3 is actually over for a couple of days, There are different opinions on when a commitfest is over. In my opinion, the point of a commitfest is that every patch that someone submits gets enough review so that the patch author knows what he needs to do next. It's not determined by a date, but by progress. wouldn't it be better to bounce back patches marked as waiting on author and work on the rest needing review? Yep, it's time to do that. I have now marked those patches that have been in Waiting on Author state, but have already been reviewed to some extent, as Returned with Feedback. I kept a two patches: * Flush buffers belonging to unlogged tables, and * Function returning the timestamp of last transaction The first one is a bug-fix, and the second one is stalled by a bug-fix that hasn't been applied yet. We should deal with them ASAP. There are still plenty of patches in Needs review state. We got below 20 at one point, but are back to 24 now. Reviewers: Please *review a patch*! We need to get closure to every patch. Patch authors: Nag the reviewer of your patch. If that doesn't help, contact other people who you think would be qualified to review your patch, and ask them nicely to review your patch. - Heikki -- 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] Commitfest status
CF3 is actually over for a couple of days, wouldn't it be better to bounce back patches marked as waiting on author and work on the rest needing review? -- Michael -- 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] Commitfest status
On 10.9.2014 22:39, Heikki Linnakangas wrote: The bad news is that the rest don't seem to moving graduating from the Needs Review state. ISTM that many patches (a) in 'needs review' actually have a review, or are being thoroughly discussed (b) in 'waiting on author' are not really waiting, because the author already responded / posted a new version of the patch Except that the patch status was not updated, whis makes it really difficult to spot patches that currently need a review :-( regards Tomas -- 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] Commitfest status
On 11/09/14 18:59, Tomas Vondra wrote: On 10.9.2014 22:39, Heikki Linnakangas wrote: The bad news is that the rest don't seem to moving graduating from the Needs Review state. ISTM that many patches (b) in 'waiting on author' are not really waiting, because the author already responded / posted a new version of the patch Except that the patch status was not updated, whis makes it really difficult to spot patches that currently need a review :-( I think that still means patch is 'waiting for author' as author is responsible for changing this. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commitfest status
On 11.9.2014 21:14, Petr Jelinek wrote: On 11/09/14 18:59, Tomas Vondra wrote: On 10.9.2014 22:39, Heikki Linnakangas wrote: The bad news is that the rest don't seem to moving graduating from the Needs Review state. ISTM that many patches (b) in 'waiting on author' are not really waiting, because the author already responded / posted a new version of the patch Except that the patch status was not updated, whis makes it really difficult to spot patches that currently need a review :-( I think that still means patch is 'waiting for author' as author is responsible for changing this. In that case it was meant as a plea to the authors to update this ;-) Tomas -- 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] Commitfest status
Hi, I've update my entry. [rounding up time value less than its unit] https://commitfest.postgresql.org/action/patch_view?id=1507 regards, - Tomonari Katsumata (2014/09/12 7:03), Tomas Vondra wrote: On 11.9.2014 21:14, Petr Jelinek wrote: On 11/09/14 18:59, Tomas Vondra wrote: On 10.9.2014 22:39, Heikki Linnakangas wrote: The bad news is that the rest don't seem to moving graduating from the Needs Review state. ISTM that many patches (b) in 'waiting on author' are not really waiting, because the author already responded / posted a new version of the patch Except that the patch status was not updated, whis makes it really difficult to spot patches that currently need a review :-( I think that still means patch is 'waiting for author' as author is responsible for changing this. In that case it was meant as a plea to the authors to update this ;-) Tomas -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Commitfest status
Another commitfest week has passed, and here are still. There are now 24 patches in Needs Review state, and 8 in Ready for Committer. I'm not paying attention to the Waiting on Author patches - once we're close to zero on the other patches, those will be bounced back. The good news is that all but two patches have a reviewer assigned. The bad news is that the rest don't seem to moving graduating from the Needs Review state. Reviewers: please review your patches. And then pick another patch to review; one of the two that have no reviewer assigned yet, or some other patch. It is only good to have more than on reviewer for the same patch. Patch authors: if your patch is not getting reviewed in a timely fashion, in a few days, please send an off-list note to the reviewer and ask what the status is. The reviewer might not realize that you're waiting. - Heikki -- 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] Commitfest status
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote: 5. Better syntax for REINDEX 6. pgcrypto: support PGP signatures 7. pgcrypto: PGP armour headers [...] I think the latter 3 patches are missing a reviewer because no-one is interested in them. There was some discussion on the REINDEX syntax, and whether we want the patch at all. The pgcrypto patches have received zero comments. I'm certainly interested in the pgcrypto patches and can look at REINDEX this weekend. If you think that a feature is worthwhile, please sign up as a reviewer. If these patches don't have a reviewer assigned by the end of the week, I'm going to mark them as Rejected on the grounds that no-one cares about them. Looks like Joel has picked up the pgcrypto ones (though I'd still be interested to help as a committer) and I'll get with Vik about the REINDEX patch. Thanks! Stephen signature.asc Description: Digital signature
Re: [HACKERS] Commitfest status
On Thu, Sep 4, 2014 at 12:42 PM, Stephen Frost sfr...@snowman.net wrote: I'm certainly interested in the pgcrypto patches and can look at REINDEX this weekend. I'm thinking of picking one of these up, but I'll be on vacation next week, and so probably won't get to it until the 15th at the earliest. The hash join patch looks interesting. -- Peter Geoghegan -- 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] Commitfest status
Stephen Frost wrote: * Heikki Linnakangas (hlinnakan...@vmware.com) wrote: 5. Better syntax for REINDEX I think the latter 3 patches are missing a reviewer because no-one is interested in them. There was some discussion on the REINDEX syntax, and whether we want the patch at all. The pgcrypto patches have received zero comments. I'm certainly interested in the pgcrypto patches and can look at REINDEX this weekend. I can take care of the reindex one --- I'm already on it anyway, waiting for Vik to post the updated version per the respective thread. -- Álvaro Herrerahttp://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commitfest status
* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: Stephen Frost wrote: * Heikki Linnakangas (hlinnakan...@vmware.com) wrote: 5. Better syntax for REINDEX I think the latter 3 patches are missing a reviewer because no-one is interested in them. There was some discussion on the REINDEX syntax, and whether we want the patch at all. The pgcrypto patches have received zero comments. I'm certainly interested in the pgcrypto patches and can look at REINDEX this weekend. I can take care of the reindex one --- I'm already on it anyway, waiting for Vik to post the updated version per the respective thread. Works for me. I've marked you as reviewer. I'll check out some of the 'ready for committer' ones. Thanks! Stephen signature.asc Description: Digital signature
Re: [HACKERS] Commitfest status
We now have 32 patches in Needs Review state, and 7 of those don't have a reviewer assigned. They are: 1. Grouping Sets 2. hash join - dynamic bucket count 3. Enable WAL archiving even in standby 4. Selectivity estimation for inet operators 5. Better syntax for REINDEX 6. pgcrypto: support PGP signatures 7. pgcrypto: PGP armour headers Out of these, the first 4 have generated a fair amount of discussion on the list, but no-one has dared to put down their name as a reviewer. What is the real status of these patches, are the authors really waiting for a review at this stage? Authors: please speak up and update the status to Returned with Feedback or Waiting on Author, if you know how to proceed. Others: If you have been involved in the discussions, please sign up as a reviewer and make a decision on how to move forward with the patch. I think the latter 3 patches are missing a reviewer because no-one is interested in them. There was some discussion on the REINDEX syntax, and whether we want the patch at all. The pgcrypto patches have received zero comments. If you think that a feature is worthwhile, please sign up as a reviewer. If these patches don't have a reviewer assigned by the end of the week, I'm going to mark them as Rejected on the grounds that no-one cares about them. - Heikki -- 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] Commitfest status
Hi 2014-09-03 13:18 GMT+02:00 Heikki Linnakangas hlinnakan...@vmware.com: We now have 32 patches in Needs Review state, and 7 of those don't have a reviewer assigned. They are: 1. Grouping Sets I plan to do review of Grouping Sets, but I am afraid so I cannot to do in next two weeks. Regards Pavel 2. hash join - dynamic bucket count 3. Enable WAL archiving even in standby 4. Selectivity estimation for inet operators 5. Better syntax for REINDEX 6. pgcrypto: support PGP signatures 7. pgcrypto: PGP armour headers Out of these, the first 4 have generated a fair amount of discussion on the list, but no-one has dared to put down their name as a reviewer. What is the real status of these patches, are the authors really waiting for a review at this stage? Authors: please speak up and update the status to Returned with Feedback or Waiting on Author, if you know how to proceed. Others: If you have been involved in the discussions, please sign up as a reviewer and make a decision on how to move forward with the patch. I think the latter 3 patches are missing a reviewer because no-one is interested in them. There was some discussion on the REINDEX syntax, and whether we want the patch at all. The pgcrypto patches have received zero comments. If you think that a feature is worthwhile, please sign up as a reviewer. If these patches don't have a reviewer assigned by the end of the week, I'm going to mark them as Rejected on the grounds that no-one cares about them. - Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Commitfest status
The first week of the commitfest is now behind us. There are still 15 patches in Needs Review state, with no reviewer assigned. Please pick a patch and review! There are 20 patches in Needs Review state, with a reviewer assigned. If you have signed up as the reviewer, please proceed with the review. If you have submitted a patch for this commitfest, please check the status of your patch. If it is in Waiting for author state, you are expected to submit a new version of the patch, addressing any review comments you have received. If you don't have the time to update your patch in the next few days, please mark your patch as Returned with Feedback and resubmit for the next commitfest. If your patch is in Waiting on Author state, but you don't know what you should do to it, ask for clarification. Committers: Please pick a patch that's been marked for Ready for Committer, verify that it has been adequately reviewed, and proceed to commit or bounce it back. - Heikki -- 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] commitfest status
On Wed, Jul 30, 2014 at 10:57 PM, Robert Haas robertmh...@gmail.com wrote: Hi, Is anybody working on closing out the in progress CommitFest? https://commitfest.postgresql.org/action/commitfest_view?id=22 If you or others don't have any objection, then I will do this on coming weekend. I think anything that is waiting on author should certainly be bounced at this point, and stuff that never got reviewed In past, I have seen that we try to make sure that each patch gets atleast one review in CF, so do you think we should try that this time as well (I think patches which don't have even one review are not too many). To be honest, I don't have any concrete plan to make that happen except for identifying such patches and request on list for a review of those patches or may be try to review myself for one or more of those. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Re: [HACKERS] commitfest status
On Thu, Jul 31, 2014 at 3:45 PM, Amit Kapila amit.kapil...@gmail.com wrote: In past, I have seen that we try to make sure that each patch gets atleast one review in CF, so do you think we should try that this time as well (I think patches which don't have even one review are not too many). To be honest, I don't have any concrete plan to make that happen except for identifying such patches and request on list for a review of those patches or may be try to review myself for one or more of those. By looking at the commit fest app... Some patches did not get a review and do not have assigned reviewers: - CSN snapshots - Event trigger, object creation - Partial sort - Refactor SSL code to support other SSL implementations Not the easiest ones. Some have reviewers but didn't get a review: - Reducing impact of hints/cleanup for SELECTs - pg_shmem_allocations view - contrib/fastbloat - tool for quickly assessing bloat stats for a table There are as well a couple of patches that have received some comments but seem somewhat in a stale state: - KNN-GiST with recheck has received comments from Heikki that have not been addressed, so I switched it now to Waiting on author - Patch for generic atomics has received some feedback but status is unclear by looking at the commit fest app. - Per table autovacuum vacuum cost parameters behavior change Regards, -- Michael -- 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] commitfest status
At 2014-07-30 13:27:24 -0400, robertmh...@gmail.com wrote: Hi, Is anybody working on closing out the in progress CommitFest? Yes. I was away for a few days, but I'm back at work now and will move the patches. -- Abhijit -- 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] commitfest status
On Thu, Jul 31, 2014 at 1:36 PM, Abhijit Menon-Sen a...@2ndquadrant.com wrote: At 2014-07-30 13:27:24 -0400, robertmh...@gmail.com wrote: Is anybody working on closing out the in progress CommitFest? Yes. I was away for a few days, but I'm back at work now and will move the patches. Okay. It makes sense if you could do this as you are already aware of status for most of patches. Thanks. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
[HACKERS] commitfest status
Hi, Is anybody working on closing out the in progress CommitFest? https://commitfest.postgresql.org/action/commitfest_view?id=22 I think anything that is waiting on author should certainly be bounced at this point, and stuff that never got reviewed or is ready for committer should probably be moved to the next CF. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commitfest Status: Sudden Death Overtime
On Thu, 2011-07-21 at 00:21 +0200, Florian Pflug wrote: There's a small additional concern, though, which is that there's an XPath 2.0 spec out there, and it modifies the type system and data model rather heavily. So before we go adding functions, it'd probably be wise to check that we're not painting ourselves into a corner. Why not just write XPATH2() function conforming to XPath 2.0 spec if the new spec is substancially different ? -- --- Hannu Krosing PostgreSQL Infinite Scalability and Performance Consultant PG Admin Book: http://www.2ndQuadrant.com/books/ -- 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] Commitfest Status: Sudden Death Overtime
[ having now read the relevant threads a bit more carefully ... ] Florian Pflug f...@phlo.org writes: On Jul18, 2011, at 22:19 , Tom Lane wrote: Yeah, it's not clear to me either which of those are still reasonable candidates for committing as-is. There are actually three XML-related patches from me in the queue. I'll try to give an overview of their states - as perceived by me, of course. If people want to comment on this, I suggest to do that that either on the existing threads from these patches or on new ones, but not on this one - lest confusion ensues. * Bugfix for XPATH() if text or attribute nodes are selected https://commitfest.postgresql.org/action/patch_view?id=580 Makes XPATH() return valid XML if text or attribute are selected. I'm not aware of any issues with that one, other than Radoslaw's unhappiness about the change of behaviour. Since the current behaviour is very clearly broken (as in dump, reload, ka-Woom), I'm not prepared to accept that as a show-stopper. I think we ought to apply this one. I agree that returning invalid XML is not acceptable. * Bugfix for XPATH() if expression returns a scalar value https://commitfest.postgresql.org/action/patch_view?id=565 Makes XPATH() support XPath expressions which compute a scalar value, not a node set (i.e. apply a top-level function such as name()). Currently, we return an empty array in that case. Peter Eisentraut initially seemed to prefer creating separate functions for that (XPATH_STRING, ...). I argued against that, on the grounds that that'd make it impossible to evaluate user-supplied XPath expression (since you wouldn't know which function to use). I haven't heard back from him after that argument. I find your argument against XPATH_STRING() a bit unconvincing. The use case for that is not where you are trying to evaluate an unknown, arbitrary XPath expression; it's where you are evaluating an expression that you *know* returns string (ie, it has name() or some other string returning function at top level) and you'd like a string, thanks, not something that you have to de-escape in order to get a string. Of course this use-case could also be addressed by providing a de-escape function, but I don't really think that de_escape(xpath(...)[1]) is a particularly friendly or efficient notation. Now, these statements are not arguments against the patch --- as is, XPATH() is entirely useless for expressions that return scalars, and with the patch it at least does something usable. So I think we should apply it. But there is room here for more function(s) to provide more convenient functionality for the special case of expressions returning strings. I'd be inclined to provide xpath_number and xpath_bool too, although those are less essential since a cast will get the job done. There's some code-style aspects I don't care for in the submitted patch, but I'll go clean those up and commit 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] Commitfest Status: Sudden Death Overtime
On Jul20, 2011, at 23:35 , Tom Lane wrote: I find your argument against XPATH_STRING() a bit unconvincing. The use case for that is not where you are trying to evaluate an unknown, arbitrary XPath expression; it's where you are evaluating an expression that you *know* returns string (ie, it has name() or some other string returning function at top level) and you'd like a string, thanks, not something that you have to de-escape in order to get a string. Hm, maybe I didn't make myself clear. I'm not against having special-case functions like XPATH_STRING() at all, as long as there's a general-purpuse function like XPATH() that deal with every expression you throw at it. There's a small additional concern, though, which is that there's an XPath 2.0 spec out there, and it modifies the type system and data model rather heavily. So before we go adding functions, it'd probably be wise to check that we're not painting ourselves into a corner. Of course this use-case could also be addressed by providing a de-escape function, but I don't really think that de_escape(xpath(...)[1]) is a particularly friendly or efficient notation. Yeah, that's pretty ugly. Having XMLESCAPE/XMLUNESCAPE (with types TEXT - XML and XML - TEXT) would probably still be a good idea though, even if it no replacement for XPATH_STRING(). Now, these statements are not arguments against the patch --- as is, XPATH() is entirely useless for expressions that return scalars, and with the patch it at least does something usable. So I think we should apply it. Cool, so we're on the same page. But there is room here for more function(s) to provide more convenient functionality for the special case of expressions returning strings. I'd be inclined to provide xpath_number and xpath_bool too, although those are less essential since a cast will get the job done. No objection here. I do have a number of XML-related stuff that I'd like to do for 9.2, actually. I'll write up a proposal once this commit-fest is over, and I'll include XPATH_STRINGS and friends. There's some code-style aspects I don't care for in the submitted patch, but I'll go clean those up and commit it. I'd offer to fix them, but I somehow have the feeling that you're already in the middle of it ;-) best regards, Florian Pflug -- 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] Commitfest Status: Sudden Death Overtime
Florian Pflug f...@phlo.org writes: There's a small additional concern, though, which is that there's an XPath 2.0 spec out there, and it modifies the type system and data model rather heavily. So before we go adding functions, it'd probably be wise to check that we're not painting ourselves into a corner. Good point. Has anybody here looked at that? 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] Commitfest Status: Sudden Death Overtime
On 2011-07-18 21:59, Robert Haas wrote: There are only two patches left and I think we really ought to try to take a crack at doing something with them. Yeb is working on the userspace access vector cache patch, which I think is going drag on longer than we want keep the CommitFest open, but I'm OK with giving it a day or two to shake out. At the end if this day I'm nearing the 'my head a splode' moment, which is more caused by trying to get my brain around selinux and it's postgresql policy, than the actual patch to review. I've verified that the patch works as indicated by KaiGai-san, but reading and understanding the code to say anything useful about it will take a few more hours, which will be tomorrow. regards, Yeb -- 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] Commitfest Status: Sudden Death Overtime
Robert Haas robertmh...@gmail.com writes: On Mon, Jul 18, 2011 at 4:19 PM, Tom Lane t...@sss.pgh.pa.us wrote: If you mean the business about allowing GUCs in postgresql.conf to be applied even if there are semantic errors elsewhere, I'm just as happy to let Alexey or Florian have a go at it first, if they want. The real question at the moment is do we have consensus about changing that? Because if we do, the submitted patch is certainly not something to commit as-is, and should be marked Returned With Feedback. I'm not totally convinced. The proposed patch is pretty small, and seems to stand on its own two feet. I don't hear anyone objecting to your proposed plan, but OTOH it doesn't strike me as such a good plan that we should reject all other improvements in the meantime. Maybe I'm missing something... To me, the proposed patch adds another layer of contortionism on top of code that's already logically messy. I find it pretty ugly, and would prefer to try to simplify the code before not after we attempt to deal with the feature the patch wants to add. 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] Commitfest Status: Sudden Death Overtime
Excerpts from Tom Lane's message of mar jul 19 12:09:24 -0400 2011: Robert Haas robertmh...@gmail.com writes: On Mon, Jul 18, 2011 at 4:19 PM, Tom Lane t...@sss.pgh.pa.us wrote: If you mean the business about allowing GUCs in postgresql.conf to be applied even if there are semantic errors elsewhere, I'm just as happy to let Alexey or Florian have a go at it first, if they want. The real question at the moment is do we have consensus about changing that? Because if we do, the submitted patch is certainly not something to commit as-is, and should be marked Returned With Feedback. I'm not totally convinced. The proposed patch is pretty small, and seems to stand on its own two feet. I don't hear anyone objecting to your proposed plan, but OTOH it doesn't strike me as such a good plan that we should reject all other improvements in the meantime. Maybe I'm missing something... To me, the proposed patch adds another layer of contortionism on top of code that's already logically messy. I find it pretty ugly, and would prefer to try to simplify the code before not after we attempt to deal with the feature the patch wants to add. +1. Alexey stated that he would get back on this patch for reworks. -- Álvaro Herrera alvhe...@commandprompt.com The PostgreSQL Company - Command Prompt, Inc. 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] Commitfest Status: Sudden Death Overtime
On Fri, Jul 15, 2011 at 5:05 PM, Josh Berkus j...@agliodbs.com wrote: As you can probably tell, we are not ready to end the commitfest. (I think Robert gave me this CF to show why even talking about a one-week mini-fest is a fantasy. If so, successful.). Heh, heh. Well, it wasn't that premeditated, but I'm always glad to reach a meeting of the minds. :-) These are complex and need review by advanced hackers. They are also often interdependant. As such, I'd like to automatically move his patches to the next CF and ask that hackers who are engaged in working on them continue to do so between CFs. There are only two patches left and I think we really ought to try to take a crack at doing something with them. Yeb is working on the userspace access vector cache patch, which I think is going drag on longer than we want keep the CommitFest open, but I'm OK with giving it a day or two to shake out. Aside from the benefit of reviewing the actual patch, I see that Yeb is pushing on KaiGai to do further work on the documentation, which I think is of great value. I will review the other patch - on shared object labels - RSN. PATCHES WHICH I MOVED TO THE NEXT CF 9-2011: * Collect frequency statistics and selectivity estimation for arrays * Allow multiple Postgres clusters running on the same machine to distinguish themselves in the event log * lazy vxid locks I'm not clear on your criteria for moving these patches, as they seem to be in somewhat different states. The first one is WIP, and it doesn't really matter whether you move it to the next CommitFest or just mark it returned with feedback. There is active development work going on there, so it's not going to get committed at this point. But the other two are basically just things we didn't get around to reviewing. With respect to the lazy vxid lock patch, it looks to me like Jeff has done a bit of review, and I think the real question here is whether or not we want to go ahead and make that change (with some stylistic and cosmetic corrections) or wait until we have a more complex solution to the spinlock contention problems mapped out. On a pgbench run with 8 clients on a 32-core machine, I see about a 2% speedup from that patch on pgbench -S, and it grows to 8% at 32 clients. At 80 clients (but still just a 32-core box), the results bounce around more, but taking the median of three five-minute runs, it's an 11% improvement. To me, that's enough to make it worth applying, especially considering that what is 11% on today's master is, in raw TPS, equivalent to maybe 30% of yesterday's master (prior to the fast relation lock patch being applied). More, it seems pretty clear that this is the conceptually right thing to do, even if it's going to require some work elsewhere to file down all the rough edges thus exposed. If someone objects to that, then OK, we should talk about that: but so far I don't think anyone has expressed strong opposition: in which case I'd like to fix it up and get it in. With respect to the event-log patch, MauMau has resubmitted that to the next CommitFest, so that's fine as far as it goes. But it might make sense to see if we can twist Magnus's arm into re-reviewing it now while it's fresh in his mind, rather than waiting another two or three months. PATCHES WHICH HAVE BEEN UPDATED AND NEED FURTHER REVIEW: * Cascade Replication No update. PATCHES STILL UNDER ACTIVE DISCUSSION: * Add ability to constrain backend temporary file space Now committed, by Tom. PATCHES I CAN'T FIGURE OUT THE STATUS OF: * pg_comments system view I reviewed this and marked it Returned with Feedback. * Bugfix for XPATH() if expression returns a scalar value No update. So, down to a fairly limited list, except that we need a lot of committing. We're down to three patches that fall into this category: two XML patches by Florian, which have been somewhat derailed by an argument about whether values of type xml should, in fact, be required to be valid xml (I think you know my vote on this one...); and an error-reporting patch that Tom weighed in on over the weekend. This last suffers from the issue that it's not quite clear whether Tom is going to do the work or whether he's expecting the submitter to do it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commitfest Status: Sudden Death Overtime
On Fri, Jul 15, 2011 at 10:05 PM, Josh Berkus j...@agliodbs.com wrote: PATCHES WHICH HAVE BEEN UPDATED AND NEED FURTHER REVIEW: * Cascade Replication Sorry, too busy reviewing to take note of this. I expect to commit when its tested and ready. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commitfest Status: Sudden Death Overtime
Robert Haas robertmh...@gmail.com writes: We're down to three patches that fall into this category: two XML patches by Florian, which have been somewhat derailed by an argument about whether values of type xml should, in fact, be required to be valid xml (I think you know my vote on this one...); Yeah, it's not clear to me either which of those are still reasonable candidates for committing as-is. and an error-reporting patch that Tom weighed in on over the weekend. This last suffers from the issue that it's not quite clear whether Tom is going to do the work or whether he's expecting the submitter to do it. If you mean the business about allowing GUCs in postgresql.conf to be applied even if there are semantic errors elsewhere, I'm just as happy to let Alexey or Florian have a go at it first, if they want. The real question at the moment is do we have consensus about changing that? Because if we do, the submitted patch is certainly not something to commit as-is, and should be marked Returned With Feedback. 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] Commitfest Status: Sudden Death Overtime
Simon, * Cascade Replication Sorry, too busy reviewing to take note of this. I expect to commit when its tested and ready. So, would that be this commitfest, or next commitfest? -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.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] Commitfest Status: Sudden Death Overtime
Robert, * Collect frequency statistics and selectivity estimation for arrays * Allow multiple Postgres clusters running on the same machine to distinguish themselves in the event log * lazy vxid locks I'm not clear on your criteria for moving these patches, as they seem to be in somewhat different states. For the array criteria, it took me until the last week of the CF to find a reviewer. That reviewer found a number of issues, and the submitter submitted an updated patch. It looks quite likely that work on that patch will get updated in the next couple weeks but not immediately. For the eventlog, MauMau had submitted an updated patch, but all of our Windows hackers had let me know that they were unavailable for the next couple weeks for review or commit. For lazy VXID locks, I'd the impression that we had an ongoing discussion about whether we were going to apply it or not, and you were on vacation for the last week of the CF. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.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] Commitfest Status: Sudden Death Overtime
On Mon, Jul 18, 2011 at 4:19 PM, Tom Lane t...@sss.pgh.pa.us wrote: and an error-reporting patch that Tom weighed in on over the weekend. This last suffers from the issue that it's not quite clear whether Tom is going to do the work or whether he's expecting the submitter to do it. If you mean the business about allowing GUCs in postgresql.conf to be applied even if there are semantic errors elsewhere, I'm just as happy to let Alexey or Florian have a go at it first, if they want. The real question at the moment is do we have consensus about changing that? Because if we do, the submitted patch is certainly not something to commit as-is, and should be marked Returned With Feedback. I'm not totally convinced. The proposed patch is pretty small, and seems to stand on its own two feet. I don't hear anyone objecting to your proposed plan, but OTOH it doesn't strike me as such a good plan that we should reject all other improvements in the meantime. Maybe I'm missing something... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commitfest Status: Sudden Death Overtime
On Jul18, 2011, at 22:19 , Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: We're down to three patches that fall into this category: two XML patches by Florian, which have been somewhat derailed by an argument about whether values of type xml should, in fact, be required to be valid xml (I think you know my vote on this one...); Yeah, it's not clear to me either which of those are still reasonable candidates for committing as-is. There are actually three XML-related patches from me in the queue. I'll try to give an overview of their states - as perceived by me, of course. If people want to comment on this, I suggest to do that that either on the existing threads from these patches or on new ones, but not on this one - lest confusion ensues. * Bugfix for XPATH() if text or attribute nodes are selected https://commitfest.postgresql.org/action/patch_view?id=580 Makes XPATH() return valid XML if text or attribute are selected. I'm not aware of any issues with that one, other than Radoslaw's unhappiness about the change of behaviour. Since the current behaviour is very clearly broken (as in dump, reload, ka-Woom), I'm not prepared to accept that as a show-stopper. The question about whether values of type XML should or should not be in fact valid XML is a red herring. That question has long ago been settles by the XML type's input function, which has a pretty clear and consistent idea about what constitutes a valid value of type XML. The patch simply makes XPATH() abide by those rules, instead of making up rules of it's own pretty nilly-willy. * Bugfix for XPATH() if expression returns a scalar value https://commitfest.postgresql.org/action/patch_view?id=565 Makes XPATH() support XPath expressions which compute a scalar value, not a node set (i.e. apply a top-level function such as name()). Currently, we return an empty array in that case. Peter Eisentraut initially seemed to prefer creating separate functions for that (XPATH_STRING, ...). I argued against that, on the grounds that that'd make it impossible to evaluate user-supplied XPath expression (since you wouldn't know which function to use). I haven't heard back from him after that argument. Radoslaw liked the patch, but wanted the quoting removed - same theme as with the other patch. * XML error handling improvement to fix XPATH bug https://commitfest.postgresql.org/action/patch_view?id=579 Like that first patch, it fixes a bug where XPATH() returns invalid XML. The cause is completely different though. Here, libxml is (partially) at fault - it's parsing methods always return a document instance if a document is *structurally* valid, even if it contains semantic error like invalid namespace references. But it isn't fully prepared to actually handle these inconsistent documents - for example, when asked to render a namespace URI as text, it unconditionally assumes it doesn't have to escape it, because it may not contain special characters anway. Which, if course, isn't necessarily true for structurally valid but semantically invalid documents... valid... Fixing that wasn't possible without a major rewrite of the XML support's error handling - one must use the modern version of libxml's error handling infrastructure to actually be able to detect these semantic error reliably and distinguish them from mere warnings. Noah Misch has reviewed that patch pretty extensively (Thanks again, Noah!), and I've resolved all his concerns regarding the implementation. I haven't seen a single argument *against* applying this so far. best regards, Florian Pflug -- 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] Commitfest Status: Sudden Death Overtime
On Jul18, 2011, at 22:19 , Tom Lane wrote: and an error-reporting patch that Tom weighed in on over the weekend. This last suffers from the issue that it's not quite clear whether Tom is going to do the work or whether he's expecting the submitter to do it. If you mean the business about allowing GUCs in postgresql.conf to be applied even if there are semantic errors elsewhere, I'm just as happy to let Alexey or Florian have a go at it first, if they want. The real question at the moment is do we have consensus about changing that? Because if we do, the submitted patch is certainly not something to commit as-is, and should be marked Returned With Feedback. Just to avoid false expectations here: I'd be happy to review further versions of this patch, but I won't write them. best regards, Florian Pflug -- 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] Commitfest Status: Sudden Death Overtime
On Mon, 2011-07-18 at 15:59 -0400, Robert Haas wrote: On a pgbench run with 8 clients on a 32-core machine, I see about a 2% speedup from that patch on pgbench -S, and it grows to 8% at 32 clients. At 80 clients (but still just a 32-core box), the results bounce around more, but taking the median of three five-minute runs, it's an 11% improvement. To me, that's enough to make it worth applying, especially considering that what is 11% on today's master is, in raw TPS, equivalent to maybe 30% of yesterday's master (prior to the fast relation lock patch being applied). More, it seems pretty clear that this is the conceptually right thing to do, even if it's going to require some work elsewhere to file down all the rough edges thus exposed. If someone objects to that, then OK, we should talk about that: but so far I don't think anyone has expressed strong opposition: in which case I'd like to fix it up and get it in. Agreed. I certainly like the concept of the lazy vxid patch. Regards, Jeff Davis -- 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] Commitfest Status: Sudden Death Overtime
On Jul15, 2011, at 23:05 , Josh Berkus wrote: * Bugfix for XPATH() if expression returns a scalar value Well, Peter Eisentraut seemed to disagree with my approach initially, and seemed to prefer a separate function for XPATH expressions which return a scalar value. http://archives.postgresql.org/pgsql-hackers/2011-06/msg00401.php I considered that, but came to the conclusion that it has problems of it's own, described here: http://archives.postgresql.org/pgsql-hackers/2011-06/msg00608.php Peter stopped responding at that point, so I assumed that my argument convinced him. Radoslaw complained about the fact the results of scalar values come back escaped from XPATH() with the patch applied (without it, an empty array is returned) and wanted that changed - Basically the same objection he had to my other patch which made sure text nodes are properly escaped (The fine print here is that text nodes *aren't* scalar values, they're nodes. What fun.). He did upgrade that other patch to Ready for Committer despite his objections, though. I don't know whether he wanted to do the same with this one or not, and my inquiry was left unanswered http://archives.postgresql.org/pgsql-hackers/2011-07/msg00783.php I also don't know much code review the patch has received. I didn't receive any complaints, but whether that reflects the quality of the patch or the quantity of review I leave for someone else to judge. I dunno what the best way forward is, but I'd hate to see this being bumped to the next commit-fest. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Commitfest Status: Sudden Death Overtime
All, As you can probably tell, we are not ready to end the commitfest. (I think Robert gave me this CF to show why even talking about a one-week mini-fest is a fantasy. If so, successful.). I've booted the patches which obviously aren't going to be immediately ready. Nine patches are ready for committer. The rest fall into the following buckets: KAGAI's PATCHES These are complex and need review by advanced hackers. They are also often interdependant. As such, I'd like to automatically move his patches to the next CF and ask that hackers who are engaged in working on them continue to do so between CFs. PATCHES WHICH I MOVED TO THE NEXT CF 9-2011: * Collect frequency statistics and selectivity estimation for arrays * Allow multiple Postgres clusters running on the same machine to distinguish themselves in the event log * lazy vxid locks PATCHES WHICH HAVE BEEN UPDATED AND NEED FURTHER REVIEW: * Cascade Replication PATCHES STILL UNDER ACTIVE DISCUSSION: * Add ability to constrain backend temporary file space PATCHES I CAN'T FIGURE OUT THE STATUS OF: * pg_comments system view * Bugfix for XPATH() if expression returns a scalar value So, down to a fairly limited list, except that we need a lot of committing. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.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] CommitFest Status Summary - 2010-02-14
On Tue, Feb 16, 2010 at 02:25:00PM -0800, David E. Wheeler wrote: On Feb 16, 2010, at 2:19 PM, Tim Bunce wrote: p.s. One quick heads-up: David Wheeler has reported a possible issue with Safe 2.21. I hope to investigate that tomorrow. Actually it's 2.22. 2.21 is already dead. Oops, typo. At this stage I think the problem is that the call to utf8fix (that's made when the compartment is initialized) is failing due to the extra security in Safe 2.2x. If so, PostgreSQL 9.0 will be fine but 8.x and earlier will require a patch. I'll start a new thread when I have some concrete information. Tim. -- 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] CommitFest Status Summary - 2010-02-14
On Wednesday 17 February 2010 07:39:16 Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: * Fix large object support in pg_dump. I think this is just waiting for a second opinion on whether the approach is correct. I've been meaning to look at it, but haven't gotten enough round tuits; maybe someone else would like to take a look? This is an open item, so we should really try to deal with it. Yeah, I think this is a must fix for alpha item. Will look at it tomorrow, god willin an the creek don't rise (or, given the weather around here: the power stays on). * Faster CREATE DATABASE by delaying fsync. This is really two patches now, one of which is apparently to be backpatched. This one (both parts) seems to have crashed and burned on unexpected portability issues :-(. Do we have any expectation of being able to fix it before alpha4? The Faster part has burned as well? I just looked at the buildfarm and didnt see anything. Care to point anything out? For the directory part I think we should aim for a more complete patch if I (or somebody else) can prove that its an issue (of what I am personally quite certain of). I think Greg just reverted the last patch (for 8.1). The latter for sure wont happen before weekend and I dont really see it bound for alpha4? Andres -- 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] CommitFest Status Summary - 2010-02-14
On Tue, Feb 16, 2010 at 05:22:27PM -0500, Robert Haas wrote: It's certainly been an interesting introduction to PostgreSQL development! Hopefully we haven't scared you off - your work is definitely very much appreciated (and I at least hope to see you back for 9.1)! Thanks Robert. That's nice to hear. I'd be happy to do more for 9.1 (subject to the ongoing generosity of my client http://TigerLead.com who are the ones to thank for my work on PostgreSQL). Tim. -- 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] CommitFest Status Summary - 2010-02-14
On Wed, Feb 17, 2010 at 6:39 AM, Tom Lane t...@sss.pgh.pa.us wrote: * Faster CREATE DATABASE by delaying fsync. This is really two patches now, one of which is apparently to be backpatched. This one (both parts) seems to have crashed and burned on unexpected portability issues :-(. Do we have any expectation of being able to fix it before alpha4? The current status is that the patch is in HEAD but the one line fsyncing the directory is #ifdef'd out. The backpatched fsync of the directory is entirely reverted from early branches. However I was just looking at the code and realized it has a file descriptor leak if an error occurs re-opening the files to fsync them. But then the same file descriptor leak is there if it has an error opening the destination file so I guess this isn't a new bug. -- greg -- 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] CommitFest Status Summary - 2010-02-14
I wrote: Robert Haas robertmh...@gmail.com writes: * Fix large object support in pg_dump. I think this is just waiting for a second opinion on whether the approach is correct. I've been meaning to look at it, but haven't gotten enough round tuits; maybe someone else would like to take a look? This is an open item, so we should really try to deal with it. Yeah, I think this is a must fix for alpha item. Will look at it tomorrow, god willin an the creek don't rise (or, given the weather around here: the power stays on). I've applied that patch after some revisions. The only thing still showing as open in the CommitFest webpage is the last plperl patch. I think that's actually done but not marked as committed; Andrew? 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] CommitFest Status Summary - 2010-02-14
Tom Lane wrote: I wrote: Robert Haas robertmh...@gmail.com writes: * Fix large object support in pg_dump. I think this is just waiting for a second opinion on whether the approach is correct. I've been meaning to look at it, but haven't gotten enough round tuits; maybe someone else would like to take a look? This is an open item, so we should really try to deal with it. Yeah, I think this is a must fix for alpha item. Will look at it tomorrow, god willin an the creek don't rise (or, given the weather around here: the power stays on). I've applied that patch after some revisions. The only thing still showing as open in the CommitFest webpage is the last plperl patch. I think that's actually done but not marked as committed; Andrew? sorry. fixed. 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] CommitFest Status Summary - 2010-02-14
Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: * Listen / Notify rewrite. This is the only one of the remaining patches that is not marked as Ready for Committer, but I think it would be good if someone (probably Tom) at least took a look at it. I'm not sure if it's committable at this point, but we should at least try to provide some good feedback. I will look at this one. It'd be nice to get it in if at all possible, because the existing listen/notify infrastructure won't play very nicely with HS --- eg, inspecting pg_listener on the slave might yield the false impression that some of the slave-side backends had active LISTENs because of chance matches of PID. Good point. Is pg_listener the only place we expose PIDs in heap files? I know we expose them in views but those are not affected by HS, I believe. -- Bruce Momjian br...@momjian.ushttp://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] CommitFest Status Summary - 2010-02-14
Tim Bunce wrote: On Sun, Feb 14, 2010 at 10:14:28PM -0500, Andrew Dunstan wrote: Robert Haas wrote: We're down to 5 patches remaining, and 1 day remaining, so it's time to try to wrap things up. * Package namespace and Safe init cleanup for plperl. Andrew Dunstan is taking care of this one, I believe. I will get this in, with changes as discussed recently. Here's a small extra patch for your consideration. It addresses a couple of minor loose-ends in plperl: - move on_proc_exit() call to after the plperl_*_init() calls so on_proc_exit will only be called if plperl_*_init() succeeds (else there's a risk of on_proc_exit consuming all the exit hook slots) - don't allow use of Safe version 2.21 as that's broken for PL/Perl. I have committed all the plperl changes that were under discussion, including this, and the change to the log level of perl warnings. Thanks for all your work, Tim, you have certainly given plperl a huge booster shot. 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] CommitFest Status Summary - 2010-02-14
On Tue, Feb 16, 2010 at 04:42:29PM -0500, Andrew Dunstan wrote: Tim Bunce wrote: On Sun, Feb 14, 2010 at 10:14:28PM -0500, Andrew Dunstan wrote: Robert Haas wrote: We're down to 5 patches remaining, and 1 day remaining, so it's time to try to wrap things up. * Package namespace and Safe init cleanup for plperl. Andrew Dunstan is taking care of this one, I believe. I will get this in, with changes as discussed recently. Here's a small extra patch for your consideration. It addresses a couple of minor loose-ends in plperl: - move on_proc_exit() call to after the plperl_*_init() calls so on_proc_exit will only be called if plperl_*_init() succeeds (else there's a risk of on_proc_exit consuming all the exit hook slots) - don't allow use of Safe version 2.21 as that's broken for PL/Perl. I have committed all the plperl changes that were under discussion, including this, and the change to the log level of perl warnings. Thanks for all your work, Tim, you have certainly given plperl a huge booster shot. Thanks Andrew! And many thanks to you and the rest of the PostgreSQL developers for all your support/resistance/reviews along the way. The final changes are certainly better in many ways (though not all ;-) from my original patches. It's certainly been an interesting introduction to PostgreSQL development! Tim. p.s. One quick heads-up: David Wheeler has reported a possible issue with Safe 2.21. I hope to investigate that tomorrow. -- 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] CommitFest Status Summary - 2010-02-14
On Feb 16, 2010, at 2:19 PM, Tim Bunce wrote: It's certainly been an interesting introduction to PostgreSQL development! Interesting, eh? Look forward to your blog post about the experience. ;-P Tim. p.s. One quick heads-up: David Wheeler has reported a possible issue with Safe 2.21. I hope to investigate that tomorrow. Actually it's 2.22. 2.21 is already dead. David -- 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] CommitFest Status Summary - 2010-02-14
It's certainly been an interesting introduction to PostgreSQL development! Hopefully we haven't scared you off - your work is definitely very much appreciated (and I at least hope to see you back for 9.1)! ...Robert -- 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] CommitFest Status Summary - 2010-02-14
Robert Haas robertmh...@gmail.com writes: * Fix large object support in pg_dump. I think this is just waiting for a second opinion on whether the approach is correct. I've been meaning to look at it, but haven't gotten enough round tuits; maybe someone else would like to take a look? This is an open item, so we should really try to deal with it. Yeah, I think this is a must fix for alpha item. Will look at it tomorrow, god willin an the creek don't rise (or, given the weather around here: the power stays on). * Faster CREATE DATABASE by delaying fsync. This is really two patches now, one of which is apparently to be backpatched. This one (both parts) seems to have crashed and burned on unexpected portability issues :-(. Do we have any expectation of being able to fix it before alpha4? 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] CommitFest Status Summary - 2010-02-14
On Sun, Feb 14, 2010 at 10:14:28PM -0500, Andrew Dunstan wrote:
Robert Haas wrote:
We're down to 5 patches remaining, and 1 day remaining, so it's time
to try to wrap things up.
* Package namespace and Safe init cleanup for plperl. Andrew Dunstan
is taking care of this one, I believe.
I will get this in, with changes as discussed recently.
Here's a small extra patch for your consideration.
It addresses a couple of minor loose-ends in plperl:
- move on_proc_exit() call to after the plperl_*_init() calls
so on_proc_exit will only be called if plperl_*_init() succeeds
(else there's a risk of on_proc_exit consuming all the exit hook slots)
- don't allow use of Safe version 2.21 as that's broken for PL/Perl.
Tim.
commit d8c0d4e63c00606db95f95a9c8f2b7ccf3c819b3
Author: Tim Bunce tim.bu...@pobox.com
Date: Mon Feb 15 11:18:07 2010 +
Move on_proc_exit to after init (that may fail). Avoid Safe 2.21.
diff --git a/src/pl/plperl/plperl.c b/src/pl/plperl/plperl.c
index e950222..16d74a7 100644
--- a/src/pl/plperl/plperl.c
+++ b/src/pl/plperl/plperl.c
@@ -365,8 +365,6 @@ select_perl_context(bool trusted)
{
/* first actual use of a perl interpreter */
- on_proc_exit(plperl_fini, 0);
-
if (trusted)
{
plperl_trusted_init();
@@ -379,6 +377,10 @@ select_perl_context(bool trusted)
plperl_untrusted_interp = plperl_held_interp;
interp_state = INTERP_UNTRUSTED;
}
+
+ /* successfully initialized, so arrange for cleanup */
+ on_proc_exit(plperl_fini, 0);
+
}
else
{
@@ -685,8 +687,9 @@ plperl_trusted_init(void)
/*
* Reject too-old versions of Safe and some others:
* 2.20: http://rt.perl.org/rt3/Ticket/Display.html?id=72068
+ * 2.21: http://rt.perl.org/rt3/Ticket/Display.html?id=72700
*/
- if (safe_version_x100 209 || safe_version_x100 == 220)
+ if (safe_version_x100 209 || safe_version_x100 == 220 || safe_version_x100 == 221)
{
/* not safe, so disallow all trusted funcs */
eval_pv(PLC_SAFE_BAD, FALSE);
--
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] CommitFest Status Summary - 2010-02-14
(2010/02/14 13:34), Robert Haas wrote: * Fix large object support in pg_dump. I think this is just waiting for a second opinion on whether the approach is correct. I've been meaning to look at it, but haven't gotten enough round tuits; maybe someone else would like to take a look? This is an open item, so we should really try to deal with it. Do I have anything I can work on this right now? Because I'll be unavailable at the next week, I'd like to fix up it within this week, if possible. -- OSS Platform Development Division, NEC KaiGai Kohei kai...@ak.jp.nec.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] CommitFest Status Summary - 2010-02-14
Robert Haas robertmh...@gmail.com writes: * Listen / Notify rewrite. This is the only one of the remaining patches that is not marked as Ready for Committer, but I think it would be good if someone (probably Tom) at least took a look at it. I'm not sure if it's committable at this point, but we should at least try to provide some good feedback. I will look at this one. It'd be nice to get it in if at all possible, because the existing listen/notify infrastructure won't play very nicely with HS --- eg, inspecting pg_listener on the slave might yield the false impression that some of the slave-side backends had active LISTENs because of chance matches of PID. 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] CommitFest Status Summary - 2010-02-14
I will look at this one. It'd be nice to get it in if at all possible, because the existing listen/notify infrastructure won't play very nicely with HS --- eg, inspecting pg_listener on the slave might yield the false impression that some of the slave-side backends had active LISTENs because of chance matches of PID. It'll also serve a major need for integrating PostgreSQL with caching infrastructures. So it's not just an insider feature. --Josh Berkus -- 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] CommitFest Status Summary - 2010-02-14
Robert Haas wrote: We're down to 5 patches remaining, and 1 day remaining, so it's time to try to wrap things up. * Package namespace and Safe init cleanup for plperl. Andrew Dunstan is taking care of this one, I believe. I will get this in, with changes as discussed recently. I also have two small action items I want to get into the alpha: * change perl warnings to emit messages at WARNING rather than NOTICE level as recently discussed. This can probably be done as part of the above patch. * add the query text to auto-explain output, as I proposed some time ago, and was generally approved. I think it's desirable for us to have this from the get-go for XML explain output. This isn't in the commitfest, but the patch is very small, and it's really a cleanup item, I think. I will be returning home in the next 24 hours and will try to get all this in within 24 hours of that. But I can't make it by tomorrow. I'm too tired now and I want to avoid mistakes. 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
[HACKERS] CommitFest Status Summary - 2010-02-14
We're down to 5 patches remaining, and 1 day remaining, so it's time to try to wrap things up. * Fix large object support in pg_dump. I think this is just waiting for a second opinion on whether the approach is correct. I've been meaning to look at it, but haven't gotten enough round tuits; maybe someone else would like to take a look? This is an open item, so we should really try to deal with it. * Faster CREATE DATABASE by delaying fsync. This is really two patches now, one of which is apparently to be backpatched. Greg Stark was going to commit it, but perhaps if he isn't around someone else should pick it up. * Provide rowcount for utility SELECTs. Bruce just posted an updated version of this patch. I think it's pretty much ready to go. * Package namespace and Safe init cleanup for plperl. Andrew Dunstan is taking care of this one, I believe. * Listen / Notify rewrite. This is the only one of the remaining patches that is not marked as Ready for Committer, but I think it would be good if someone (probably Tom) at least took a look at it. I'm not sure if it's committable at this point, but we should at least try to provide some good feedback. ...Robert -- 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] CommitFest status summary 2010-01-27
Hi, Boszormenyi Zoltan írta: Greg Smith írta: 4) Investigate and be explicit about the potential breakage here both for libpq clients and at least one additional driver too. If I saw a demonstration that this didn't break the JDBC driver, for example, I'd feel a lot better about the patch. ... (JDBC discussed to be non-vulnerable) The question is whether new versions of psqlODBC and the old ones shipped in unixODBC handle the change well. I looked at the unixODBC PG driver sources. Both the old and new versions return rowcount for STMT_TYPE_SELECT as the number of tuples returned, it doesn't look at the command status. But they both seems to be broken for INSERTs, as the source interprets the number found after the first ' ' (space) character, they would return 0 for WITHOUT OIDS case. I am talking about these files: unixODBC-x.y.z/Drivers/PostgreSQL/results.c unixODBC-x.y.z/Drivers/Postgre7.1/results.c Look at the SQLRowCount() function. The current psqlODBC driver versions do it in a similar way. They don't look at the actual command tag, if there is a space character in the command status string after trimming it, the string after the space gets interpreted with atoi(). This code also ignores that INSERT returns 2 values, the first value will be returned for rowcount. This means that the more recent ODBC drivers seem to start returning rowcount for utility SELECTs with this protocol change. I haven't tested it though. So, the latest JDBC won't change behaviour without code changes, ODBC may or may not, depending on the version. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil. (Matthew 5:37) - basics of digital technology. May your kingdom come - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ -- 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] CommitFest Status Summary - 2010-02-03
Robert Haas wrote: Here's an overview of where we stand with the remaining 14 patches, according to my best understanding of the situation. * rbtree - I have done a lot of work reviewing this, and Mark Cave-Ayland has done some work on it, too. But there are some unanswered performance questions that need to be addressed before commit. This is another one that could really use some more eyes on it. * knngist - The third remaining big patch. Mark Cave-Ayland volunteered to review this one, too, but so far no review has been posted on -hackers. I know that the PostGIS folks would really like to have this, but time is growing short. Yes. I'm currently working on the knngist patch now, although sadly work got side-tracked onto the rbtree patch since it is a requirement for the knngist patch. Now that the rbtree patch is in reasonably good shape, I intend to focus the rest of my time working on the knngist patch exclusively. ATB, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] CommitFest Status Summary - 2010-02-03
Here's an overview of where we stand with the remaining 14 patches, according to my best understanding of the situation. * Fix large object support in pg_dump - I haven't looked at this, but it seems like it's relatively close to being ready for commit. We need to get this one done as it is a release blocker (IMO). * Remove gcc dependency in definition of inline functions - We have been waiting for an updated patch since January 19th. If there is no update in the next few days, I will marked this as Returned with Feedback. * Faster CREATE DATABASE by delaying fsync - There seems to be a consensus that this is doing something sensible, but we're still arguing about how things should be named and documented. Doesn't seem like anything insurmountable, though. * More frame options in window functions - Tom has listed himself as the committer on this one, so I infer that he is planning to commit it after suitable editorialization. This is a big patch. * Writeable CTEs - Another big patch. As per today's discussion, at a minimum, it still needs some cleanup work and quite a bit of additional documentation. I have set it back to Waiting on Author. Even once that's fixed, I suspect this is going to need some attention from Tom prior to commit. * Provide rowcount for utility SELECTs - There's some debate about whether this is a good idea, but I believe most people are in favor of it, provided that we can cover all cases. This one really needs some more review. * Make PostgreSQL binaries use the new PQconnectdbParams() libpq functions - I believe Joe Conway is working on this. * rbtree - I have done a lot of work reviewing this, and Mark Cave-Ayland has done some work on it, too. But there are some unanswered performance questions that need to be addressed before commit. This is another one that could really use some more eyes on it. * knngist - The third remaining big patch. Mark Cave-Ayland volunteered to review this one, too, but so far no review has been posted on -hackers. I know that the PostGIS folks would really like to have this, but time is growing short. * plpython3 - It doesn't seem likely that this will go into core for 9.0, but Nathan Boley is going to review it anyhow, which is a good thing. * Add on_trusted_init and on_untrusted_init to plperl - Still arguing about the GUC names and details, but seems to be more or less on track. * Package namespace and Safe init cleanup for plperl - From the discussion, this one seems to be in pretty good shape, too. * Listen / Notify rewrite - The fourth and final major patch remaining for this CommitFest. There are still ongoing discussions about the concurrency handling in this patch, and some other open issues, too, like limiting the payload to ASCII. I know this is another big feature people would like to see in, but we're running out of time to get it stabilized. * xpath non-nodeset result enabling - We've been waiting on an updated patch since January 17th. On the 28th, Scott Bailey said he might take a look at it, but we've heard nothing since. If there is no update in the next couple of days, I will mark this Returned with Feedback. ...Robert -- 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] CommitFest status summary 2010-01-27
Hi,
Greg Smith írta:
Provide rowcount for utility SELECTs
I think I can write a review for this one right now based on the
discussion that's already happened:
-Multiple people think the feature is valuable and it seems worth
exploring
-The right way to handle the protocol change here is still not clear
-There are any number of subtle ways clients might be impacted by this
change, and nailing that down and determining who might break is an
extremely wide ranging bit of QA work that's barely been exploring yet
That last part screams returned with feedback for something
submitted to the last CF before beta to me. As a candidate for
9.1-alpha1 where there's plenty of time to figure out what it breaks
and revert if that turns out to be bad? That sounds like a much
better time to be fiddling with something in this area.
I understand your position, this is a subtle change that might
turn out to break clients, indeed.
I would like to see the following in order to make this patch have a
shot at being comittable:
1) Provide some examples showing how the feature would work in
practice and of use-cases for it.
I'll try to explore all the things affected by this change
and reflect them in a regression test.
2) To start talking about what's going to break, some notes about what
this does to the regression tests would be nice.
Is there a way to run a regression test under src/test/regress so the
command status string is also written into the *.out file? It doesn't
seem to me so because all the current *.out files only contain
results for tuple-returning statements and
src/test/regress/pg_regress_main.c
runs psql in quiet mode.
So, first I suggest dropping the -q option from the psql command line
in psql_start_test() in pg_regress_main.c to be able to see the command
strings.
3) Demonstrate with example sessions the claims that there are no
backward compatibility issues here. I read when you mix old server
with new clients or new server with old client, it will just work as
before, but until I see a session proving that I have to assume
that's based on code inspections rather than actual tests, and
therefore not necessarily true. (Nothing personal, Zoltan--just done
way too much QA in the last year to believe anything I'm told about
code without a matching demo).
4) Investigate and be explicit about the potential breakage here both
for libpq clients and at least one additional driver too. If I saw a
demonstration that this didn't break the JDBC driver, for example, I'd
feel a lot better about the patch.
I thought the libpq change was obvious.
strncmp(status, SELECT , 7) /* one space at the end */
doesn't match SELECT (no spaces). So:
1. old server sends SELECT, the code in the new libpq client
gets a doesn't match, PQcmdTuples() returns .
2. new server sends SELECT N, old libpq client doesn't look
for strings starting with SELECT, PQcmdTuples() returns
I looked at the latest JDBC source (currently it's postgresql-jdbc-8.4-701)
these are the places I found where the command status interpreted
in core/v3/QueryExecutorImpl.java:
private String receiveCommandStatus() throws IOException {
//TODO: better handle the msg len
int l_len = pgStream.ReceiveInteger4();
//read l_len -5 bytes (-4 for l_len and -1 for trailing \0)
String status = pgStream.ReceiveString(l_len - 5);
//now read and discard the trailing \0
pgStream.Receive(1);
if (logger.logDebug())
logger.debug( =BE CommandStatus( + status + ));
return status;
}
and
private void interpretCommandStatus(String status, ResultHandler
handler) {
int update_count = 0;
long insert_oid = 0;
if (status.startsWith(INSERT) || status.startsWith(UPDATE)
|| status.startsWith(DELETE) || status.startsWith(MOVE))
{
try
{
update_count = Integer.parseInt(status.substring(1 +
status.lastIndexOf(' ')));
if (status.startsWith(INSERT))
insert_oid = Long.parseLong(status.substring(1 +
status.indexOf(' '),
status.lastIndexOf(' ')));
}
catch (NumberFormatException nfe)
{
handler.handleError(new PSQLException(GT.tr(Unable to
interpret the update count in command completion tag: {0}., status),
PSQLState.CONNECTION_FAILURE));
return ;
}
}
handler.handleCommandStatus(status, update_count, insert_oid);
}
receiveCommandStatus() reads everything up to and including
the zero termination byte. interpretCommandStatus() handles
only the old strings expected to carry the rowcount.
This wouldn't break for the new SELECT N string as it
falls into the latest (here nonexisting) else branch, effectively
ignoring SELECT or SELECT N.
The version of the same in ./core/v2/QueryExecutorImpl.java is:
protected
Re: [HACKERS] CommitFest status summary 2010-01-27
On Wed, Jan 27, 2010 at 11:13 PM, Greg Smith g...@2ndquadrant.com wrote: Robert Haas wrote: plpython3 - no reviewer yet This whole feature seems quite interesting, and I'm really impressed at how much work James has put into rethinking what a Python PL should look like. But isn't the fact that there isn't even a reviewer for it yet evidence it needs more time to develop a bit of a community first before being considered for core? I agree. I think this needs to live outside of core for the time being. I don't think we can commit to maintaining a second PL/python implementation in core because two or three people are excited about it. It may be really great, and if there are some small changes to core that are needed to support this living outside of core, then I think we should consider those. But committing the whole patch does not seem like a wise idea to me. We are then on the hook to maintain it, essentially forever, and it's not clear that there is enough community support for this for us to be certain of that. If the community around this grows, we can certainly revisit for 9.1. Provide rowcount for utility SELECTs I think I can write a review for this one right now based on the discussion that's already happened: -Multiple people think the feature is valuable and it seems worth exploring -The right way to handle the protocol change here is still not clear -There are any number of subtle ways clients might be impacted by this change, and nailing that down and determining who might break is an extremely wide ranging bit of QA work that's barely been exploring yet That last part screams returned with feedback for something submitted to the last CF before beta to me. As a candidate for 9.1-alpha1 where there's plenty of time to figure out what it breaks and revert if that turns out to be bad? That sounds like a much better time to be fiddling with something in this area. I feel a bit differently about this. No matter when we make a change like this, there will be some risk of breaking clients. Many of those clients may be proprietary, closed-source software, and we have no way of estimating how many such clients there are in total nor what percentage of them are likely to be broken by this change. Looking at a few of the open source clients and trying to judge whether they will break may be worthwhile, but I think the primary thing we need here is a better understanding of exactly which commands this change will affect and some thought about how plausible it is that someone could be depending on those tags. In particular, it seems to me that it's rather unlikely that anyone is depending on the command tag from an operation like CREATE TABLE AS or SELECT INTO, because isn't it always going to be SELECT? Furthermore, if we are going to ever change this in an incompatible way that may break clients, isn't 9.0 exactly the right time to do that? If that doesn't scream big changes coming, proceed with caution, I don't know what would. ...Robert -- 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] CommitFest status summary 2010-01-27
Robert Haas escribió: Furthermore, if we are going to ever change this in an incompatible way that may break clients, isn't 9.0 exactly the right time to do that? If that doesn't scream big changes coming, proceed with caution, I don't know what would. I agree with this -- if we're ever going to change this, it must be now. -- 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] CommitFest status summary 2010-01-27
On Wed, Jan 27, 2010 at 4:05 PM, Robert Haas robertmh...@gmail.com wrote: Waiting for Re-Review (5) = Writeable CTEs Set this ready for commit. For such a small patch, it's a wonderful feature. I think it deserves a fair shot on this 'fest. insert/returning/subquery is far and away one of the most requested features, and this patch delivers the goods in a very elegant way. merlin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] CommitFest status summary 2010-01-27
We have 20 remaining patches to deal with for the 2010-01 CommitFest. I've attempted to break down the status of these patches below. The good news is that almost half of the remaining patches are either already marked as Ready for Committer, or have already been reviewed once and will likely be marked Ready for Committer when they are re-reviewed. If you are the reviewer for one of these patches, please re-review and mark it either Waiting on Author if you find additional issues or Ready for Committer if it looks good. The somewhat-less-good news is that we still have at least four patches that have not been reviewed at all, and one of those (plpython3) has been very difficult to find a reviewer for. Some of the perl patches have not yet been reviewed either, but I'm a little less concerned about those because it seems that Andrew is working on those anyway: still, if anyone feels inclined to volunteer, I believe Andrew has said he would appreciate another pair of eyes. Overall, I would say we're doing fairly well at working through this: but most of the big patches are still ahead of us. ...Robert Ready for Committer (4) === Faster CREATE DATABASE by delaying fsync More frame options in window functions Typed tables libpq new connect function (PQconnectParams) Waiting for Re-Review (5) = Writeable CTEs Listen / Notify rewrite Prevent renaming on multiple inherited column listagg aggregate quoting psql variables (needs reverse review) Waiting for Initial Review (4) == Remove obscure permission checks in FindConversion() Provide rowcount for utility SELECTs knngist (WIP) plpython3 - no reviewer yet Waiting for Updated Patch (2) = Remove gcc dependency in definition of inline functions xpath non-nodeset result enabling Other (5) = Fix large object support in pg_dump - Tom Lane suggested a new approach, nobody has coded it rbtree - Needs both more review and some updates from the author. Add on_perl_init and proper destruction to plperl Add on_trusted_init and on_untrusted_init to plperl Package namespace and Safe init cleanup for plperl - No reviewer listed, but Andrew Dunstan is working on these. -- 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] CommitFest status summary 2010-01-27
Robert Haas wrote: Some of the perl patches have not yet been reviewed either, but I'm a little less concerned about those because it seems that Andrew is working on those anyway: still, if anyone feels inclined to volunteer, I believe Andrew has said he would appreciate another pair of eyes. I have to be away from base for a couple of weeks starting Sunday in family business. That will impact my ability to deal with those remaining patches. In any case, I would still like more eyes on these last pieces, which are a bit more complex and certainly more controversial than the last few. 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] CommitFest status summary 2010-01-27
Robert Haas wrote: Waiting for Initial Review (4) == plpython3 - no reviewer yet This whole feature seems quite interesting, and I'm really impressed at how much work James has put into rethinking what a Python PL should look like. But isn't the fact that there isn't even a reviewer for it yet evidence it needs more time to develop a bit of a community first before being considered for core? This seems to me like the sort of patch you'd want to play with for a month or two before you could really have an informed opinion about how working with it flows compared to the existing implementation, and that's not going to be possible here. Provide rowcount for utility SELECTs I think I can write a review for this one right now based on the discussion that's already happened: -Multiple people think the feature is valuable and it seems worth exploring -The right way to handle the protocol change here is still not clear -There are any number of subtle ways clients might be impacted by this change, and nailing that down and determining who might break is an extremely wide ranging bit of QA work that's barely been exploring yet That last part screams returned with feedback for something submitted to the last CF before beta to me. As a candidate for 9.1-alpha1 where there's plenty of time to figure out what it breaks and revert if that turns out to be bad? That sounds like a much better time to be fiddling with something in this area. I would like to see the following in order to make this patch have a shot at being comittable: 1) Provide some examples showing how the feature would work in practice and of use-cases for it. 2) To start talking about what's going to break, some notes about what this does to the regression tests would be nice. 3) Demonstrate with example sessions the claims that there are no backward compatibility issues here. I read when you mix old server with new clients or new server with old client, it will just work as before, but until I see a session proving that I have to assume that's based on code inspections rather than actual tests, and therefore not necessarily true. (Nothing personal, Zoltan--just done way too much QA in the last year to believe anything I'm told about code without a matching demo). 4) Investigate and be explicit about the potential breakage here both for libpq clients and at least one additional driver too. If I saw a demonstration that this didn't break the JDBC driver, for example, I'd feel a lot better about the patch. Expecting a community reviewer to do all that just to confirm this code change is worthwhile seems a pretty big stretch to me, and I wouldn't consider it very likely that set of work could get finished in time for this CF. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.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] CommitFest status/management
On Tue, Dec 1, 2009 at 9:43 AM, Robert Haas robertmh...@gmail.com wrote: On Tue, Dec 1, 2009 at 9:42 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: If we went with Bruce's interpretation, we could have a committer field that only appears when the status is Claimed by Committer or Committed and the contents of that field could be displayed in parentheses in the status column, like this: Claimed by Committer (Tom Lane). If we went with Andrew's interpretation, we would need a completely separate column, because there wouldn't be any logical relationship between the status field and the committer field. Any other votes? Tom? I'm happy with Andrew's interpretation --- I just want a separate text field for inserting a committer's name. I don't want any magic behavior of that field. OK, I'll add a separate text field for the committer's name, but for now it won't display on the summary page, just the detail page. Done. ...Robert -- 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] CommitFest status/management
Robert Haas wrote: I'm happy with Andrew's interpretation --- I just want a separate text field for inserting a committer's name. I don't want any magic behavior of that field. OK, I'll add a separate text field for the committer's name, but for now it won't display on the summary page, just the detail page. Done. Cool. Thanks. 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] CommitFest status/management
On Mon, Nov 30, 2009 at 10:16 PM, Greg Smith g...@2ndquadrant.com wrote: Considering that one of those was a holiday week with a lot of schedule disruption proceeding it, I don't know how much faster things could have moved. There were large chunks of the reviewer volunteers who wanted only jobs they could finish before the holiday, and others who weren't available at all until afterwards. And I don't know about every else, but I took all four days off and started today behind by several hundred list messages. I was planning to start nagging again tomorrow, hoping that most would be caught up from any holiday time off too by then. Right now, of the 16 patches listed in Needs Review besides the ECPG ones Michael is working through, the breakdown is like this: Not reviewed at all yet: 6 Reviewed once, updated, waiting for re-review: 10 So the bulk of the problem for keeping the pipeline moving is in these re-reviews holding up transitions to Ready for committer. I've had some discussion with Robert about how to better distinguish in the management app when the reviewer has work they're expected to do vs. when they think they're done with things. We're converging toward a more clear set of written guidelines to provide for managing future CommitFests as part of that, right now there's a few too many fuzzy parts for my liking. If the need here is to speed up how fast things are fed to committers, we can certainly do that. The current process still favors having reviewers do as much as possible first, as shown by all the stuff sitting in the re-review queue. The work we're waiting on them for could be done by the committers instead if we want to shorten the whole process a bit. I don't think that's really what you want though. I think the pressure has to be applied all through the process. People who haven't provided a review by now are certainly overdue for a polite poke, Thanksgiving or no Thanksgiving. If the first review doesn't happen until the third week of the CommitFest, how is the patch going to get a fair shake by the end of the fourth one? I mean, if that happens to a small number of patches, OK, but when it's 20% of what's in the CommitFest, it seems like it's bound to lead to a huge crunch at the end. In any case, unlike last CommitFest, where the problem was a lack of adequate committer activity, it's pretty clear that the the problem this CommitFest has been a combination of slow reviews and slow updates by patch authors. I've been keeping a loose eye on the patch queue and my impression is that there has rarely been more than 1 patch other than HS + SR in the Ready for Committer state, and many times zero. That's means the pipeline is stalling, and that's bad. ...Robert -- 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] CommitFest status/management
On Mon, Nov 30, 2009 at 11:08 PM, Tom Lane t...@sss.pgh.pa.us wrote: Andrew Dunstan and...@dunslane.net writes: As I have observed before, I think we need some infrastructure to help committers claim items, so we don't duplicate work. Robert acknowledged the need for a claimed by committer field in the fest application, but he hasn't got round to it yet. In the meantime I've been adding a Taking this one... type of comment to an entry I want to claim. Sorry I haven't gotten around to this. Beyond being a little burned out a little bit, I have been a little bit under the weather and a little occupied with life apart from PostgreSQL, as if there were such a thing. Anyway, one of the concerns I have about this is that adding another field to the commitfest_view page seems as though it will create some layout issues - the leftmost column will get squished. I could (a) go ahead and do it anyway or (b) do it, but modify the layout in some unspecified way so that it doesn't impact the format as much or of course (c) not do it. Any thoughts? It would also like to clarify the use case for this a little bit more. Is this just to track patches which committers are in the process of committing (or have committed)? Or would a committer potentially set this on some patch that was still being reviewed, and if so would that mean don't review this any more because I'm taking over or I'm planning to pick this up when the review process completes or something else? Thanks, ...Robert -- 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] CommitFest status/management
Robert Haas wrote: On Mon, Nov 30, 2009 at 11:08 PM, Tom Lane t...@sss.pgh.pa.us wrote: Andrew Dunstan and...@dunslane.net writes: As I have observed before, I think we need some infrastructure to help committers claim items, so we don't duplicate work. Robert acknowledged the need for a claimed by committer field in the fest application, but he hasn't got round to it yet. ?In the meantime I've been adding a Taking this one... type of comment to an entry I want to claim. Sorry I haven't gotten around to this. Beyond being a little burned out a little bit, I have been a little bit under the weather and a little occupied with life apart from PostgreSQL, as if there were such a thing. Anyway, one of the concerns I have about this is that adding another field to the commitfest_view page seems as though it will create some layout issues - the leftmost column will get squished. I could (a) go ahead and do it anyway or (b) do it, but modify the layout in some unspecified way so that it doesn't impact the format as much or of course (c) not do it. Any thoughts? It would also like to clarify the use case for this a little bit more. Is this just to track patches which committers are in the process of committing (or have committed)? Or would a committer potentially set this on some patch that was still being reviewed, and if so would that mean don't review this any more because I'm taking over or I'm planning to pick this up when the review process completes or something else? I am thinking we can just add a new status, claimed by committer and not bother about adding a new column with the committer name. -- Bruce Momjian br...@momjian.ushttp://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] CommitFest status/management
Bruce Momjian wrote: It would also like to clarify the use case for this a little bit more. Is this just to track patches which committers are in the process of committing (or have committed)? Or would a committer potentially set this on some patch that was still being reviewed, and if so would that mean don't review this any more because I'm taking over or I'm planning to pick this up when the review process completes or something else? I am thinking we can just add a new status, claimed by committer and not bother about adding a new column with the committer name. I think it would be more flexible and useful to be able to claim it before the review is finished. It would mean in effect I am following this and intend to commit it when it's ready. 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] CommitFest status/management
On Tue, Dec 1, 2009 at 8:27 AM, Andrew Dunstan and...@dunslane.net wrote: Bruce Momjian wrote: It would also like to clarify the use case for this a little bit more. Is this just to track patches which committers are in the process of committing (or have committed)? Or would a committer potentially set this on some patch that was still being reviewed, and if so would that mean don't review this any more because I'm taking over or I'm planning to pick this up when the review process completes or something else? I am thinking we can just add a new status, claimed by committer and not bother about adding a new column with the committer name. I think it would be more flexible and useful to be able to claim it before the review is finished. It would mean in effect I am following this and intend to commit it when it's ready. If we went with Bruce's interpretation, we could have a committer field that only appears when the status is Claimed by Committer or Committed and the contents of that field could be displayed in parentheses in the status column, like this: Claimed by Committer (Tom Lane). If we went with Andrew's interpretation, we would need a completely separate column, because there wouldn't be any logical relationship between the status field and the committer field. Any other votes? Tom? On a possibly related note, I am not totally sure that we want to enshrine the principle that committers categorically won't touch patches that are not yet marked Ready for Committer. For major patches like SE-PostgreSQL or the partitioning stuff, early committer involvement is an extremely important ingredient for success. And, I have an uncomfortable feeling about having Tom, Bruce, and Andrew all intentionally sitting on the bench waiting for reviews to complete while the days tick away. On the other hand, I also agree with Tom's point that, if completing reviews doesn't affect whether the patch gets in, there's less incentive for people to review. ...Robert -- 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] CommitFest status/management
Robert Haas robertmh...@gmail.com writes: On Mon, Nov 30, 2009 at 11:08 PM, Tom Lane t...@sss.pgh.pa.us wrote: Robert acknowledged the need for a claimed by committer field in the fest application, but he hasn't got round to it yet. Sorry I haven't gotten around to this. Beyond being a little burned out a little bit, I have been a little bit under the weather and a little occupied with life apart from PostgreSQL, as if there were such a thing. Anyway, one of the concerns I have about this is that adding another field to the commitfest_view page seems as though it will create some layout issues - the leftmost column will get squished. I could (a) go ahead and do it anyway or (b) do it, but modify the layout in some unspecified way so that it doesn't impact the format as much or of course (c) not do it. Any thoughts? I would be satisfied if there were a claimed by field in the per-patch detail page, which is where you'd have to go to set it anyway. If you want you could add an additional status value claimed by committer so it'd be visible in the main page. It would also like to clarify the use case for this a little bit more. It's to keep committers from treading on each others' toes. Right now, if say Andrew is working over a patch with intent to commit, there's no visibility of that fact in the fest status. I would imagine that a patch should not normally get into this state until it's been marked ready for committer by the reviewer. Except perhaps in cases where the reviewer and committer are the same person. 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] CommitFest status/management
Robert Haas robertmh...@gmail.com writes: If we went with Bruce's interpretation, we could have a committer field that only appears when the status is Claimed by Committer or Committed and the contents of that field could be displayed in parentheses in the status column, like this: Claimed by Committer (Tom Lane). If we went with Andrew's interpretation, we would need a completely separate column, because there wouldn't be any logical relationship between the status field and the committer field. Any other votes? Tom? I'm happy with Andrew's interpretation --- I just want a separate text field for inserting a committer's name. I don't want any magic behavior of that field. On a possibly related note, I am not totally sure that we want to enshrine the principle that committers categorically won't touch patches that are not yet marked Ready for Committer. No, but I think that should be the default assumption once a reviewer has been assigned. If the reviewer doesn't totally fall down on the job, he/she should be allowed to finish reviewing. 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] CommitFest status/management
On Tue, Dec 1, 2009 at 9:42 AM, Tom Lane t...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: If we went with Bruce's interpretation, we could have a committer field that only appears when the status is Claimed by Committer or Committed and the contents of that field could be displayed in parentheses in the status column, like this: Claimed by Committer (Tom Lane). If we went with Andrew's interpretation, we would need a completely separate column, because there wouldn't be any logical relationship between the status field and the committer field. Any other votes? Tom? I'm happy with Andrew's interpretation --- I just want a separate text field for inserting a committer's name. I don't want any magic behavior of that field. OK, I'll add a separate text field for the committer's name, but for now it won't display on the summary page, just the detail page. ...Robert -- 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] CommitFest status/management
BTW, if you have time for any purely cosmetic details ... the way the CommitFest field on a patch detail page works has always struck me as weird. It's a data field, and so if it has any behavior at all that behavior ought to involve modifying its value. But what it actually is is a navigation link. I think you ought to drop it down to a plain text field and add a Back to CommitFest link to the page header, similar to the way navigation works on other dependent pages. 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] CommitFest status/management
Robert Haas wrote: OK, I'll add a separate text field for the committer's name, but for now it won't display on the summary page, just the detail page. Perhaps it could go underneath the reviewer names, maybe in a different color. (And yes, like many of us I suck at GUI design, so feel free to discount any suggestions I make in that area). 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] CommitFest status/management
Bruce Momjian wrote: So, if someone writes a patch, and it is reviewed, and the patch author updates the patch and replies, it still should be reviewed again before being committed? That's generally how things were expected to happen--to at least double-check that the proposed fixes match what was expected. I don't think it was spelled out very well in the past though. Also, we are two weeks into the commit fest and we have more unapplied patches than applied ones. Considering that one of those was a holiday week with a lot of schedule disruption proceeding it, I don't know how much faster things could have moved. There were large chunks of the reviewer volunteers who wanted only jobs they could finish before the holiday, and others who weren't available at all until afterwards. And I don't know about every else, but I took all four days off and started today behind by several hundred list messages. I was planning to start nagging again tomorrow, hoping that most would be caught up from any holiday time off too by then. Right now, of the 16 patches listed in Needs Review besides the ECPG ones Michael is working through, the breakdown is like this: Not reviewed at all yet: 6 Reviewed once, updated, waiting for re-review: 10 So the bulk of the problem for keeping the pipeline moving is in these re-reviews holding up transitions to Ready for committer. I've had some discussion with Robert about how to better distinguish in the management app when the reviewer has work they're expected to do vs. when they think they're done with things. We're converging toward a more clear set of written guidelines to provide for managing future CommitFests as part of that, right now there's a few too many fuzzy parts for my liking. If the need here is to speed up how fast things are fed to committers, we can certainly do that. The current process still favors having reviewers do as much as possible first, as shown by all the stuff sitting in the re-review queue. The work we're waiting on them for could be done by the committers instead if we want to shorten the whole process a bit. I don't think that's really what you want though. -- Greg Smith2ndQuadrant Baltimore, MD PostgreSQL Training, Services and Support g...@2ndquadrant.com www.2ndQuadrant.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] CommitFest status/management
Greg Smith wrote: If the need here is to speed up how fast things are fed to committers, we can certainly do that. The current process still favors having reviewers do as much as possible first, as shown by all the stuff sitting in the re-review queue. The work we're waiting on them for could be done by the committers instead if we want to shorten the whole process a bit. I don't think that's really what you want though. As I have observed before, I think we need some infrastructure to help committers claim items, so we don't duplicate work. Right now the only items marked ready for reviewer are Streaming Replication and Hot Standby, which I imagine Heiki will be handling. I'm going to look at the YAML format for EXPLAIN patch shortly. 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] CommitFest status/management
Andrew Dunstan and...@dunslane.net writes: As I have observed before, I think we need some infrastructure to help committers claim items, so we don't duplicate work. Robert acknowledged the need for a claimed by committer field in the fest application, but he hasn't got round to it yet. In the meantime I've been adding a Taking this one... type of comment to an entry I want to claim. I'm going to look at the YAML format for EXPLAIN patch shortly. Do we have consensus yet that we want YAML? It seemed, well, yet another format without all that much advantage over what's there. 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] CommitFest status/management
On Nov 30, 2009, at 8:08 PM, Tom Lane wrote: I'm going to look at the YAML format for EXPLAIN patch shortly. Do we have consensus yet that we want YAML? It seemed, well, yet another format without all that much advantage over what's there. Legibility++ David -- 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] CommitFest status/management
Tom Lane wrote: I'm going to look at the YAML format for EXPLAIN patch shortly. Do we have consensus yet that we want YAML? It seemed, well, yet another format without all that much advantage over what's there. I think you and I are the two main skeptics ;-) But we seem to be rather in the minority, and it's not terribly invasive from what I have seen so far. 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] CommitFest Status Summary - 2009-08-03
Personally I was thinking of multi-threaded pgbench as being Tatsuo-san's to commit, since that's his code originally. Ah see well that's why I post these summaries... :-) Thanks. I consider it a great honor to be allowed to commit the pacthes. -- Tatsuo Ishii SRA OSS, Inc. Japan -- 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] CommitFest Status Summary - 2009-08-03
Personally I was thinking of multi-threaded pgbench as being Tatsuo-san's to commit, since that's his code originally. Ah see well that's why I post these summaries... :-) Thanks. I consider it a great honor to be allowed to commit the pacthes. Patch committed. -- Tatsuo Ishii SRA OSS, Inc. Japan -- 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] CommitFest Status Summary - 2009-08-03
On Mon, Aug 3, 2009 at 11:22 AM, Tatsuo Ishiiis...@postgresql.org wrote: Personally I was thinking of multi-threaded pgbench as being Tatsuo-san's to commit, since that's his code originally. Ah see well that's why I post these summaries... :-) Thanks. I consider it a great honor to be allowed to commit the pacthes. Patch committed. Can you go here and change the status to Committed? https://commitfest.postgresql.org/action/patch_view?id=123 Thanks, ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] CommitFest Status Summary - 2009-08-03
We now have less than two weeks remaining in this CommitFest (assuming we stick with the usual time table of one month), and I would say we're in fairly good shape. There are less than a dozen patches left that are waiting on people other than the committers, or that are still under discussion. Here is again my best attempt to summarize which patches are waiting for which people; I've classed a handful of patches as Under Discussion, where it's not clear to me exactly who needs to take the next action for one reason or another. Anyone who is looking for a way to help is encouraged to read the threads related to the patches that are waiting on someone other than a committer, and chime in with thoughts or opinions. Several of the remaining patches are still in the queue not so much because they need review or rework, but because they lack either consensus or direction on what to do next. You don't need to be a coder to have an opinion on design. With respect to code reviewing, there is likely to be a need for some high-speed reviewing of Heikki's patches this week once Heikki has a chance to respond to feedback posted earlier in the CommitFest. I'm not sure it's going to be very realistic to get these into shape in the time that remains, but I guess we'll see (in some ways I feel that we've been somewhat unfair by not closing these out already; we've certainly given them more time than we would to a non-committer who was on vacation). We also need someone to review the rest of Greg Stark's merge append patch; Tom reviewed only the planner portions, and the assigned round-robin reviewer (Abhijit Menon-Sen) has not posted a review. ...Robert Specific Committer (11) == Revise parallel pg_restore's scheduling heuristic (Tom) Indexam API changes (Heikki, as patch author) Index-only quals (Heikki, as patch author) ECPG dynamic cursor, SQLDA support (Michael Meskes) ECPG support for string pseudo-type v2 (Michael Meskes) Determine client_encoding from client locale (Heikki, as patch author) async notifications for dblink (Joe Conway) query cancel issues in dblink (Joe Conway) Improvements for dict_xsyn extended synonym dictionary (Teodor) has_sequence_privilege() function (Joe Conway, awaiting feedback before commit) plpythonu datatype conversion improvements (Peter Eisentraut) Unspecified Committer (3) = GRANT ON ALL IN schema DefaultACLs multi-threaded pgbench Reviewer (3) Merge append (partially reviewed by Tom, needs new reviewer for rest of patch) new bytea hex output format Filtering dictionary support and unaccent dictionary Author (4) == machine-readable explain output v4 autogenerating headers bki stuff (may need to be bumped) return query and dropped columns Prefix support for synonym dictionary Under Discussion (4) Named and mixed notation for PL Support for in to_char() Parser's hook based on FuncCall (needs wider input) dependencies for generated header files -- 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] CommitFest Status Summary - 2009-08-03
Robert Haas robertmh...@gmail.com writes: Unspecified Committer (3) = GRANT ON ALL IN schema DefaultACLs multi-threaded pgbench Personally I was thinking of multi-threaded pgbench as being Tatsuo-san's to commit, since that's his code originally. 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] CommitFest Status Summary - 2009-08-03
On Sun, Aug 2, 2009 at 9:49 PM, Tom Lanet...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: Unspecified Committer (3) = GRANT ON ALL IN schema DefaultACLs multi-threaded pgbench Personally I was thinking of multi-threaded pgbench as being Tatsuo-san's to commit, since that's his code originally. Ah see well that's why I post these summaries... :-) ...Robert -- 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] CommitFest Status Summary - 2009-07-25
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Tom Lane wrote: Robert Haas robertmh...@gmail.com writes: ... One thing I have belatedly realized about this CommitFest is that we (or at least, I) did not think about asking the committers about their schedules, and it turns out that three of them - Heikki, Michael Meskes, Joe Conway - are away at the moment. About 25% of the remaining patches are waiting for one of those three people to take the next step (as either patch author, or reviewer, or committer). Well, any commitfest is going to have some issues of that sort, especially one scheduled during the summer. If we get to the point where those patches are the only ones left, and the relevant people still aren't back, I think we can just push them all to the next fest. But I doubt we are moving fast enough to make that happen. I just got home last night, and am currently plowing through my pg mailing list queue. I should be able to make progress before the weekend is out. Joe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iQIcBAEBCAAGBQJKcdITAAoJEDfy90M199hle5cP/1AiepmKpBO0LONGzX3Lu0JW L/ilfv0Ea3L/YRksld9YjaVZgMjtMXhF/srHP2L1nyTylKTeFIfYLTwjAWz79bf3 S1yamofxSvfzYYLhRcTEHE6MXaQwrGJwkzkcgsHM2E8TJm4xdFOqIqsTUqI5ExOS PclWH1W8GWC8grJ4+kzN2kOEh5hQcdq+zZeFQP5C405TVjP+AQJu3uXR44VtlExL q1VOxICUwWiXldqCiFhE6AWX1RSWWhfoaP6lkVmySyn2QVyK2JFmuF8r1XUhE7qW H/Oya7NOz3aDjziNZc20ggW63KwjLxddeCE1kkuqnnNLNEeKcbPykcZUlVgfZevv 1X71KSPNw/eMtTItkGqSEIYW7LZ622uOT1VOC0ZZcKhSnDVh7KTloiGhjUVPYeCJ SqocXN6kR1qA2z6iAxuxIZE2yl8xMA9EGecVuxDdiO/SS9cgBAgD3gxSgzsoUt7F rL+IK25+dErynMzDcVK7ZJEvQd5m8YjMAKEPLzs6ELjlt9yA6E+P8c/Tx+nEvCEu Ac+ayVsklLx8fbg4PCFY+dD7nSDEqX/1yYtZdx+6T23vx6VcAAcTVwU/O/g5FGKw 7ovpL2ruL/Gx9X527Vs2hBHOWG4odtsFyIvsQz/ZsDNftIJ7kkCgitscE8KKF4ha Im4yCTz6hpF2CBfKyYSF =rcGM -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] CommitFest Status Summary - 2009-07-25
--On Sonntag, Juli 26, 2009 15:43:28 -0400 Robert Haas robertmh...@gmail.com wrote: I think Joe is back in the next week, but I'm not sure about Michael or Heikki. Michael is on vacation, he's back next week. -- Thanks Bernd -- 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] CommitFest Status Summary - 2009-07-25
Robert Haas robertmh...@gmail.com writes: ... One thing I have belatedly realized about this CommitFest is that we (or at least, I) did not think about asking the committers about their schedules, and it turns out that three of them - Heikki, Michael Meskes, Joe Conway - are away at the moment. About 25% of the remaining patches are waiting for one of those three people to take the next step (as either patch author, or reviewer, or committer). Well, any commitfest is going to have some issues of that sort, especially one scheduled during the summer. If we get to the point where those patches are the only ones left, and the relevant people still aren't back, I think we can just push them all to the next fest. But I doubt we are moving fast enough to make that happen. Specific Committers (13) - generic explain options v3 (needs further review by Tom Lane) Actually I was waiting for the other EXPLAIN patch to come ready before looking at this, because I thought they were intertwined. Do you want this committed before that? 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] CommitFest Status Summary - 2009-07-25
On Sun, Jul 26, 2009 at 12:07 PM, Tom Lanet...@sss.pgh.pa.us wrote: Robert Haas robertmh...@gmail.com writes: ... One thing I have belatedly realized about this CommitFest is that we (or at least, I) did not think about asking the committers about their schedules, and it turns out that three of them - Heikki, Michael Meskes, Joe Conway - are away at the moment. About 25% of the remaining patches are waiting for one of those three people to take the next step (as either patch author, or reviewer, or committer). Well, any commitfest is going to have some issues of that sort, especially one scheduled during the summer. If we get to the point where those patches are the only ones left, and the relevant people still aren't back, I think we can just push them all to the next fest. But I doubt we are moving fast enough to make that happen. I think Joe is back in the next week, but I'm not sure about Michael or Heikki. Specific Committers (13) - generic explain options v3 (needs further review by Tom Lane) Actually I was waiting for the other EXPLAIN patch to come ready before looking at this, because I thought they were intertwined. Do you want this committed before that? Well, if it's OK with you, yes. I have been maintaining these as a series of stacked patches, and the latest round of refactoring on the explain-options patch has broken the machine-readable explain output patch beyond all recognition. So it costs me nothing to have you whack it around some more before committing it at this point. I think it's an independent feature: it does a bunch of refactoring, adds new syntax, and adds an actual option which makes use of that syntax. Not the most interesting option, to be sure, but one that's been requested more than once. The other alternative is to merge the two patches together and then commit the whole thing in one go. I think I like this option a little less because it means that if there turn out to be additional issues with the machine-readable explain-patch, I might end up getting nothing that actually does anything committed this CommitFest, and it will also delay the process by several days while I rework and merge the patches. But I'm willing to do it if it's the only path to getting this done. What I'm LEAST enthusiastic about is fixing the machine-readable explain output patch, then have you make some more changes to explain-options patch, then having to fix machine-readable explain output again. ...Robert -- 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] CommitFest Status Summary - 2009-07-25
Robert Haas wrote: I think Joe is back in the next week, but I'm not sure about Michael or Heikki. I'll be back on Monday 3rd of August. -- Heikki Linnakangas EnterpriseDB 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
[HACKERS] CommitFest Status Summary - 2009-07-25
All, A few hours ago I assigned a reviewer to the last patch for this CommitFest which still lacked one, with the exception of Heikki's index-only quals patch, which I'm not sure can be reviewed at this point because it depends on the indexam API changes patch, which is still up in the air. One thing I have belatedly realized about this CommitFest is that we (or at least, I) did not think about asking the committers about their schedules, and it turns out that three of them - Heikki, Michael Meskes, Joe Conway - are away at the moment. About 25% of the remaining patches are waiting for one of those three people to take the next step (as either patch author, or reviewer, or committer). That's not exactly a catastrophe considering that we have informally decided that a CommitFest is about a month long, and we're only 10 days into it, but may mean that there's not much left for non-committers to do well before all of the patches are actually dealt with. I've attached below a summary of which patches are waiting on which people, to the best of my ability to determine such things. It's basically the same information that's on commitfest.postgresql.org, but broken up differently and annotated with notes here and there. There are a couple of patches that are ostensibly waiting on reviewer activity that may really be ready for committer; the others are reviews that aren't finished, and we may want to think about adding additional reviewers to help move things along. Also, there are a few patches that are waiting on author which are nearly done, and it may make sense for someone other than the patch author to pick them up and finish them so that we can move forward with them. Any thoughts/ideas/etc. welcome. ...Robert Specific Committers (13) - generic explain options v3 (needs further review by Tom Lane) - Indexam API changes (Heikki Linnakangas as patch author) - Index-only quals (Heikki Linnakangas as patch author) - Determine cient_encoding from client locale (Heikki Linnakangas as patch author) - plpythonu datatype conversion improvements (Peter Eisentraut as committer) - dependencies for generated header files (Peter Eisentraut as reviewer) - Fix memory leak in win32 security functions (Magnus Hagander as patch author and presumed committer) - ECPG dynamic cursor, SQLDA support (Michael Meskes as reviewer) - ECPG support for string pseudo-type v2 (Michael Meskes as reviewer) - async notifications for dblink (Joe Conway as reviewer) - query cancel issues in dblink (Joe Conway as reviewer) - has_sequence_privilege() function (Joe Conway as reviewer) - Polygons (Teodor Sigaev as committer) Unspecified Committer (4) - GRANT ON ALL IN schema - Provide support for multiplexing SIGUSR1 signal - Deferrable unique constraints - DefaultACLs Reviewer (10) - ALTER TABLE ... ALTER COLUMN ... SET DISTINCT - Revise parallel pg_restore's scheduling heuristic - Merge append - Support for in to_char() (may be ready for committer) - multi-threaded pgbench (may be ready for committer) - Improvements for dict_xsyn extended synonym dictionary - new bytea hex output format - return query and dropped columns (perhaps this should be marked ready for committer?) - Prefix support for synonym dictionary (just assigned) - Filtering dictionary support and unaccent dictionary (just assigned) Author (8) - Named and mixed notation for PL - \dL for languages - WIP: TODO Item 'Add prompt escape to display the client and server versions' - hstore enhancements - Lock wait statistics (Tom doesn't like it, may be doomed) - Parser's hook based on FuncCall (seems to need major expansion, may be too much for this CF) - autogenerating headers bki stuff (Tom doesn't like it, may be doomed) - better support for win64 via intptr_t (seems to need major reworking, may be too much for this CF) Limbo (2) - machine-readable explain output v2 (can't update this patch until issues with generic explain options v3 are resolved) - report key values in duplicate-key errors (not really sure whose court the ball is in at this point) -- 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] Commitfest status?
Tom Lane napsal(a): Well, it's July 1, and time for another commit fest to begin. Do we have all the submitted patches queued up at http://wiki.postgresql.org/wiki/CommitFest:2008-07 ? There is Collation at database level patch. http://archives.postgresql.org/pgsql-hackers/2008-07/msg00019.php Please, put it on the list. I'm not able edit the wiki page now. :( Thanks Zdenek -- 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] Commitfest status?
Zdenek Kotala napsal(a): Tom Lane napsal(a): Well, it's July 1, and time for another commit fest to begin. Do we have all the submitted patches queued up at http://wiki.postgresql.org/wiki/CommitFest:2008-07 ? There is Collation at database level patch. http://archives.postgresql.org/pgsql-hackers/2008-07/msg00019.php Please, put it on the list. I'm not able edit the wiki page now. :( After short battle added. Zdenek -- 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] Commitfest status?
On Tue, Jul 1, 2008 at 4:19 PM, Tom Lane [EMAIL PROTECTED] wrote: Well, it's July 1, and time for another commit fest to begin. Do we have all the submitted patches queued up at http://wiki.postgresql.org/wiki/CommitFest:2008-07 ? we noticed the libpq events (hooks) patch was missing...so we duly added it :-). merlin -- 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] Commitfest status?
On Tuesday 01 July 2008 17:38:28 Josh Berkus wrote:
On Tue, 01 Jul 2008 16:19:39 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Well, it's July 1, and time for another commit fest to begin.
Do we have all the submitted patches queued up at
http://wiki.postgresql.org/wiki/CommitFest:2008-07 ?
I think Bruce and I have added everything submitted to June 29. I've
been offline for 36 hours, though, so I'm scanning hackers and patches
now. Help welcomed -- I'm on dial-up and it's slow.
Time for people to start volunteering to review stuff! I'll start
round-robin after a few days. So put your names on the stuff you know
you can review now.
Note that Robert Lor has an updated patch for the dtrace probes that we have
seen over here @ omniti, but I don't think he has posted it yet, so it isn't
reflected in the wiki... Robert, care to post that?
--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Commitfest status?
Well, it's July 1, and time for another commit fest to begin. Do we have all the submitted patches queued up at http://wiki.postgresql.org/wiki/CommitFest:2008-07 ? 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] Commitfest status?
Tom Lane wrote: Well, it's July 1, and time for another commit fest to begin. Do we have all the submitted patches queued up at http://wiki.postgresql.org/wiki/CommitFest:2008-07 ? I haven't yet committed the dblink patch posted here: http://archives.postgresql.org/pgsql-patches/2008-06/msg00016.php Should I post it on the wiki before committing? Either way I'll commit in the next day or so. Joe -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
