Re: [HACKERS] Kudos for Reviewers -- straw poll
On Tue, Jun 25, 2013 at 5:40 PM, Brendan Jurd dire...@gmail.com wrote: On 26 June 2013 03:17, Josh Berkus j...@agliodbs.com wrote: How should reviewers get credited in the release notes? a) not at all b) in a single block titled Reviewers for this version at the bottom. c) on the patch they reviewed, for each patch A weak preference for (c), with (b) running a close second. As others have suggested, a review that leads to significant commitable changes to the patch should bump the credit to co-authorship. I like the single block at the bottom myself, with the same provision to move a reviewer up to co-author. Should there be a criteria for a creditable review? a) no, all reviews are worthwhile b) yes, they have to do more than it compiles c) yes, only code reviews should count (b), the review should at least look at usabililty, doc, and regression test criteria even if there is no in-depth code analysis. +1 to this. Should reviewers for 9.4 get a prize, such as a t-shirt, as a promotion to increase the number of non-submitter reviewers? a) yes b) no c) yes, but submitters and committers should get it too I was going to go with b until I saw the suggestion for a PgCon ticket. I really like that idea. gabrielle
[HACKERS] Clarification of certain SQLSTATE class
I'm working with some DB2 users, converting them to Pg, and I'm a bit confused about a certain class of SQLSTATE codes, specifically 02xxx No data (http://www.postgresql.org/docs/9.2/static/errcodes-appendix.html) As an example: I enable %e in log_line_prefix so I can see the SQLSTATE values. I run an UPDATE against a non-existent row, and find that my SQLSTATE value is 0, indicating success. I understand that this could be considered a 'success' because the query didn't actually throw an error; but, based on the spec, I expected to see a SQLSTATE of 02000. I thought that Pg always generated an appropriate SQLSTATE code, and that it was just up to $client code to pick up that value, but that doesn't seem to be the case. Is this part of the SQL standard we don't implement? Thanks! gabrielle
Re: [HACKERS] [PATCH] Log crashed backend's query v3
On Wed, Oct 5, 2011 at 5:14 PM, Marti Raudsepp ma...@juffo.org wrote: I think you intended to use the Waiting on Author status -- that leaves the commitfest entry open. I will re-open the commitfest entry myself, I hope that's OK. No worries, and yeah, I picked the wrong checkbox. :) Here is version 3 of the patch. Looks good, and performs as advertised. Thanks! gabrielle -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCH] Log crashed backend's query v2
This review was compiled from a PDXPUG group review (Dan Colish, Mark Wong, Brent Dombrowski, and Gabrielle Roth). -- We all agree this is a really useful feature. The patch applies cleanly to the current git master with git apply, it's in context diff, and does what it's supposed to do on Ubuntu, OSX, and gentoo. We found a few problems with it, and we'd like to see the patch resubmitted with the following changes: Tests: - Regression test requires plpythonu; it needs to work without that. Docs: - The doc comment 'pgstat_get_backend_current_activity' doesn't match the function name 'pgstat_get_crashed_backend_activity'. Project coding guidelines: - There are some formatting problems, such as all newlines at the same indent level need to line up. (The author mentioned not [being] happy with the indenting depth, so I think this is not a surprise.) - Wayward tabs, line 2725 in pgstat.c specifically - Unknown is used a lot (see http://developer.postgresql.org/pgdocs/postgres/error-style-guide.html#AEN94099) We had some questions about ascii_safe_strncpy: - It doesn't convert just unknown encodings, it converts all encodings. Is that intentional? - Is there an existing function that already does this? Looking forward to the next revision! gabrielle (on behalf of PDXPUG) -- 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] Explicit psqlrc
On Mon, Jun 21, 2010 at 6:16 PM, Robert Haas robertmh...@gmail.com wrote: Well, that might be a good idea, too, but my expectation is that: psql -f one -f two -f three ought to behave in a manner fairly similar to: cat one two three all psql -f all and it sounds like with this patch that's far from being the case. Correct. Each is handled individually. Should I continue to check on ON_ERROR_ROLLBACK results, or bounce this back to the author? gabrielle -- 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] Explicit psqlrc
On Thu, 2010-06-17 at 14:50 -0400, Alvaro Herrera asked: How does it play with ON_ERROR_STOP/ROLLBACK? With ON_ERROR_STOP=ON, psql issues an error when it encounters one, stops processing the file that contains the error, and then continues to process any remaining files. I'm still investigating ON_ERROR_ROLLBACK. I need to tinker with it some more before I say anything concrete. On Fri, Jun 18, 2010 at 1:48 AM, Simon Riggs si...@2ndquadrant.com wrote: Also, how does it play with --single-transaction. That was buried in our original report :) BEGIN-COMMIT statements within the files cause warnings when the command is wrapped in a transaction with the -1 switch (as specified in the patch submission) To expand upon that a bit: when psql encounters a file that contains a BEGIN statement, you get the expected WARNING: there is already a transaction in progress message. The COMMIT at the end of that file (assuming the user doesn't forget it) generates a COMMIT. Commands after that commit, or in any remaining files to be processed, are dealt with according to the user's autocommit settings: - if autocommit is ON, statements in the remaining files are processed committed; the implicit COMMIT at the end of the whole thing then generates a WARNING: there is no transaction in progress message - if autocommit is OFF, statements in the remaining files generate ERROR: current transaction is aborted, commands ignored until end of transaction block messages. I would like multiple -c commands also, as well as a mix of -f and -c. Can we add that at the same time please? I'll leave this one for someone else to answer. :) gabrielle -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Review: psql-wrap-formatting/Unicode UTF-8 table formatting for psql text output
Overview: Patch to make data output that includes newlines wrapped lines consistent with the headers for that data. Link: https://commitfest.postgresql.org/action/patch_view?id=220 Submission review: * is in context diff * applies cleanly to current HEAD * includes its own test .sql file to verify new output * includes appropriate doc patches Usability review: * the patch does indeed do what it says * maintains backward compatibility, should the end-user desire it * included tests perform as advertised Coding review: * looks good to me * fits in with the surrounding code * no compiler warnings, no crashes * complete understandable docs Personally, I think this rocks. It really improves the readability of query output. gabrielle -- on behalf of the PDXPUG Patch Review Team (Dan, Mark, John, Brad, me) -- 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 Code Sprint with PUGs
On Fri, Jul 10, 2009 at 4:06 PM, Josh Berkus j...@agliodbs.com wrote: Gabrielle of PDXPUG volunteered that PUG to hold a code sprint in coordination with a commitfest sometime soon. For that event, the PDXPUG members would take on a dozen or so patches, compile and review them and submit the results. All systems are go! Date: Sept 15 Time: 6pm - 9pm PDT, which is GMT -7. We have 6 attendees. Robert Haas is going to choose 4 patches for us. Can somebody volunteer to hang out on IRC in case we have questions? Thanks! gabrielle -- 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 Code Sprint with PUGs
On Thu, Sep 3, 2009 at 10:58 AM, Robert Haasrobertmh...@gmail.com wrote: On Thu, Sep 3, 2009 at 1:54 PM, Webb Spraguewebb.spra...@gmail.com wrote: Hi Josh et al, I believe we are all still interested (Selena? Gabrielle?) Heck yes! How about this: 6:00 Tuesday evening (Pacific), the three of us (and anybody else) agree to be around a table with laptops on, cellphones ready, listening at an IRC channel. Could you assign us good patches before then (like 10)? And then we commit, commit, commit. Sounds good, already have at least someone else from #pdxpug interested too. :) Just need to pick a location. Anybody have a quiet house? I think we should think of this as a dry run where we iron out the details, and then maybe the following saturday do it again on a larger scale? Practice run was my expectation as well. Making both dates might be problematic for some people (:ahem: me) but we should have enough attendee overlap to deal with that. gabrielle -- 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 Code Sprint with PUGs
(cc'ing Webb Sprague because I believe this was actually his idea...don't want to take credit for it if so. :) ) On Fri, Jul 10, 2009 at 4:06 PM, Josh Berkusj...@agliodbs.com wrote: Gabrielle of PDXPUG volunteered that PUG to hold a code sprint in coordination with a commitfest sometime soon. For that event, the PDXPUG members would take on a dozen or so patches, compile and review them and submit the results. You also mentioned having someone In the Know (tm) available on IRC in case we have problems - I would like that if it's possible. Obviously PDXPUG won't be ready for July 15th. But could we plan this for the Sept. 15th CF? I poked around the wiki but am unclear on the timeline - would we have to be finished by Sept 15 or start on Sept 15? Also, do any other PUGs want to do this? I'll add whatever we learn to the wiki in the interest of encouraging others. gabrielle -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
