Re: [HACKERS] Kudos for Reviewers -- straw poll
On Tue, Jun 25, 2013 at 10:17 AM, Josh Berkus wrote: > How should reviewers get credited in the release notes? Without getting into how we do this, I thought it might be helpful to share the reasons why I believe recognizing and expressing gratitude to reviewers is a helpful, useful and gratifying exercise for the Postgres community. I support crediting reviewers in a more formal way than we currently do for a few different reasons. First, I believe it's worth finding a way to say "Hey, you just did something great for Postgres", publicly, to a bunch of people who could have spent their valuable time and energy in some other way. Second, reviewers get better at their work by reviewing multiple times - so I'd like to encourage people to review more than once. Third, reviewers don't always need to be expert developers, or experts at Postgres to get started, but many people who do open source work have no idea this is true. Public recognition helps make it clear that we have people who give useful reviews and are relative novices. We also have several different kinds of reviews: * "does it compile" * style/typo/easily seen bug passes * in-depth discussion of design choices, use case, interface * complex testing cases * performance testing * pre-commit checks for more subtle bugs or committer preferences. All of those, except probably the very last, can be done by people who are familiar with Postgres or its configuration, but aren't necessarily Postgres or C experts. Fourth, we have very few accepted ways to recognize contributions to Postgres. Naming in Release Notes is one way this community has consistently supported as a *public* way to say "hey, you just did something great for Postgres". The complete list of ways I'm aware of are: 1. Recognizing major, minor and emeritus contributors 2. Making someone a committer 3. Being part of the -core group 4. Naming authors by name in commit messages (but without consistent metadata, making it difficult to count well) 5. Naming authors in release notes That's pretty much it. That's great for the people who have already secured positions through seniority, or because they're amazing C hackers. I don't know if I need to lay out for everyone the value of public recognition - if you want me to I can enumerate them. But the benefits of public recognition are huge -- both in a social and a financial sense. Currently, the only way I know of to be recognized for work on Postgres that is *not* seniority or code-related is #1. If you're a reviewer, there's almost no chance you'll be recognized in that way without some additional, very significant contribution to our community. (Please let me know if I'm mistaken about this -- I only know what I know!) Adding names to Release Notes (or some variant of Release Notes) seems like a minor concession for work done that we as a community value and want to encourage. We are so few in terms of patch contributors - somewhere between 300-400 people contribute code to PostgreSQL each year based on the names I try to pull out of commits. I haven't counted how many reviewers we have who do not also contribute code. Giving people appreciation for the review work they're doing for this community, for free, is a good thing for everyone. Naming more names helps describe the true scope of our community. Spreading gratitude is good for those who thank and those who receive thanks (like, proven scientifically!). And we increase the number of people who benefit directly from the work that they do here, by giving them something they can point their boss, their company and their colleagues to. So, when we're debating *how* recognition might be done, please don't lose sight of *why* this is important in the first place. -selena -- http://chesnok.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] streaming header too small
On Wed, Feb 20, 2013 at 6:23 AM, Magnus Hagander wrote: > > On Feb 20, 2013 11:29 AM, "Heikki Linnakangas" > wrote: > > > > On 20.02.2013 02:11, Selena Deckelmann wrote: > >> > >> So, I just ran into a similar issue backing up a 9.2.1 server using > >> pg_basebackup version 9.2.3: > >> > >> pg_basebackup: starting background WAL receiver > >> pg_basebackup: streaming header too small: 25 > >> > >> > >> I've had it happen two times in a row. I'm going to try again... > >> > >> But -- what would be helpful here? I can recompile pg_basebackup with > more > >> debugging... > > > > > > Hmm, 25 bytes would be the size of the WAL data packet, if it contains > just the header and no actual WAL data. I think pg_basebackup should accept > that - it's not unreasonable that the server might send such a packet > sometimes. > > > > Looking at the walsender code, it's not supposed to ever send such a > packet. But I suspect there's one corner-case where it might: if the > current send location is at an xlogid boundary, so that we previously sent > the last byte from the last WAL segment in the previous logical xlog file, > and the WAL flush position points to byte 0 in the beginning of the new WAL > file. Both of those positions are in fact the same thing, but we have two > different ways to represent the same position. For example, if we've > already sent up to WAL position (sentPtr in walsender.c): > > > > xlogid = 4 > > xrecoff = XLogFileSize > > > > and GetFlushRecPtr() returns: > > > > xlogid = 5 > > xrecoff = 0 > > > > Those both point to the same position. But the check in XLogSend that > decides if there is any work to do uses XLByteLE() to check if they are > equal, and XLByteLE() treats the latter to be greater than the former. So, > in that situation, XLogSend() would decide that it has work to do, but > there actually isn't, so it would send 0 bytes of WAL data. > > > > I'm not sure how GetFlushRecPtr() could return such a position, though. > But I'm also not convinced that it can't happen. > > > > It would be fairly easy to fix walsender to not send anything in that > situation. It would also be easy to fix pg_basebackup to not treat it as an > error. We probably should do both. > > > > In 9.3, the XLogRecPtr representation changed so that there is only one > value for a boundary position like that, so this is a 9.2-only issue. > Thanks for the debugging, Heikki! > That does sound like a reasonable explanation and fix. Heck, probably > enough to just put the fix in pg_basebackup since it's gone in 9.3 anyway. > > But I'd really like to confirm this is the actual situation before > considering it fixed, since it's clearly very intermittent. > > Selena, was this reasonably reproducible for you? Would it be possible to > get a network trace of it to show of that's the kind of package coming > across, or by hacking up pg_basebackup to print the exact position it was > at when the problem occurred? > This is happening with a very busy 700 GB system, so I'm going to rule out a network trace out for the moment. The error is occurring "sometime" in the middle of the backup. Last time it was at least 30-40 minutes into a 2 hr backup. I'll see about hacking up pg_basebackup. I'm doing nightly backups so hopefully (?) it will happen again in the next few days. -selena -- http://chesnok.com
Re: [HACKERS] streaming header too small
On Mon, Jan 9, 2012 at 9:11 AM, Magnus Hagander wrote: > On Mon, Jan 9, 2012 at 12:00, Magnus Hagander wrote: > > On Mon, Jan 9, 2012 at 11:09, Magnus Hagander > wrote: > >> On Mon, Jan 9, 2012 at 07:34, Jaime Casanova > wrote: > >>> Hi, > >>> > >>> I was trying pg_basebackup on head, i used this command: > >>> """ > >>> postgres@jaime:/usr/local/pgsql/9.2$ bin/pg_basebackup -D $PWD/data2 > >>> -x stream -P -p 54392 > >>> """ > >>> > >>> i got this error > >>> """ > >>> 19093/19093 kB (100%), 1/1 tablespace > >>> pg_basebackup: streaming header too small: 17 > >>> pg_basebackup: child process exited with error 1 > >>> """ > >>> > >>> now, this streaming header size is defined in > >>> src/bin/pg_basebackup/receivelog.c as "#define STREAMING_HEADER_SIZE > >>> (1+8+8+8)", so WTF is this? > >>> what are these numbers? shouldn't be at least a comment explaining > >>> those? more important it's seems obvious something broke that, unless > >> > >> Those numbers are the size of WalDataMessageHeader - a struct which is > >> not available in the frontend, or at least wasn't at the time. > >> > >>> i misunderstood something which is completely possible, and that the > >>> way is do it it will broke again in the future if the header change > >> > >> Without looking at the details, I'm pretty sure it's the keepalive > >> message patch (64233902d22ba42846397cb7551894217522fad4).That one does > >> introduce a new message that's exactly that size. > >> > >> pg_basebackup assumes the only kind of messages that can arrive are > >> the data messages, and this is no longer true. But if you check the > >> code for pg_basebackup, you'll see it checks the size of the message > >> *before* it checks the type of the message, which is why you get a > >> misleading error. > >> > >> I'll dig into the details later - but you could try backing out that > >> patch to confirm if that's the problem. > > > > Confirmed that is it, and attached are two patches to fix it. The > > first one I intend to backport to 9.1, since it just fixes the error > > message. The other one is for 9.2. I'll also look at a better way to > > get that structure size. comments? > > Patch applied. > > Realized there is no need to backpatch, because this code didn't even > exist in 9.1. The streaming mode of pg_basebackup (which is the only > affected one) didn't exist then... > So, I just ran into a similar issue backing up a 9.2.1 server using pg_basebackup version 9.2.3: pg_basebackup: starting background WAL receiver pg_basebackup: streaming header too small: 25 I've had it happen two times in a row. I'm going to try again... But -- what would be helpful here? I can recompile pg_basebackup with more debugging... -selena -- http://chesnok.com
Re: [HACKERS] setting per-database/role parameters checks them against wrong context
On Mon, Oct 1, 2012 at 2:28 PM, Selena Deckelmann wrote: > On Mon, Oct 1, 2012 at 1:37 PM, Selena Deckelmann wrote: >> On Mon, Oct 1, 2012 at 1:00 PM, Tom Lane wrote: >>> Selena Deckelmann writes: >>>> The check_temp_buffers() problem seems like a regression and blocks us >>>> from upgrading to 9.2. The use case are functions that set >>>> temp_buffers and occasionally are called in a series from a parent >>>> session. The work around is... a lot of work. >>> >>> Uh ... how is that a regression? AFAIK it's been that way right along. >> >> We're running 9.0 - looks like it changed in 9.1, last revision to the >> relevant line was 6/2011. The group decided not to upgrade to 9.1 last >> year, but was going to just go directly to 9.2 in the next few weeks. > > And, I was basing the regression comment on the documentation for > temp_buffers: "The setting can be changed within individual sessions, > but only before the first use of temporary tables within the session; > subsequent attempts to change the value will have no effect on that > session." This statement has been there since at least 8.1. > > A warning, and then not failing seems more appropriate than an error, > given the documented behavior. I tried out a few things, and then realized that perhaps just adding PGC_S_SESSION to the list of sources that are at elevel WARNING partially fixes this. This doesn't fix the issue with log_statement_stats, but it makes the behavior of temp_buffers the documented behavior (no longer errors out in a transaction), while still warning the user. -selena -- http://chesnok.com session_warning.patch Description: Binary data -- 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] setting per-database/role parameters checks them against wrong context
On Mon, Oct 1, 2012 at 1:37 PM, Selena Deckelmann wrote: > On Mon, Oct 1, 2012 at 1:00 PM, Tom Lane wrote: >> Selena Deckelmann writes: >>> The check_temp_buffers() problem seems like a regression and blocks us >>> from upgrading to 9.2. The use case are functions that set >>> temp_buffers and occasionally are called in a series from a parent >>> session. The work around is... a lot of work. >> >> Uh ... how is that a regression? AFAIK it's been that way right along. > > We're running 9.0 - looks like it changed in 9.1, last revision to the > relevant line was 6/2011. The group decided not to upgrade to 9.1 last > year, but was going to just go directly to 9.2 in the next few weeks. And, I was basing the regression comment on the documentation for temp_buffers: "The setting can be changed within individual sessions, but only before the first use of temporary tables within the session; subsequent attempts to change the value will have no effect on that session." This statement has been there since at least 8.1. A warning, and then not failing seems more appropriate than an error, given the documented behavior. -selena -- http://chesnok.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] setting per-database/role parameters checks them against wrong context
On Mon, Oct 1, 2012 at 1:00 PM, Tom Lane wrote: > Selena Deckelmann writes: >> The check_temp_buffers() problem seems like a regression and blocks us >> from upgrading to 9.2. The use case are functions that set >> temp_buffers and occasionally are called in a series from a parent >> session. The work around is... a lot of work. > > Uh ... how is that a regression? AFAIK it's been that way right along. We're running 9.0 - looks like it changed in 9.1, last revision to the relevant line was 6/2011. The group decided not to upgrade to 9.1 last year, but was going to just go directly to 9.2 in the next few weeks. -selena -- http://chesnok.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] setting per-database/role parameters checks them against wrong context
On Fri, Sep 28, 2012 at 7:10 AM, Tom Lane wrote: > Peter Eisentraut writes: >> Example: >> create temporary table foo (a int); >> insert into foo values (1); >> alter role peter set temp_buffers = 120; >> ERROR: 22023: invalid value for parameter "temp_buffers": 120 >> DETAIL: "temp_buffers" cannot be changed after any temporary tables >> have been accessed in the session. > >> Another example: > >> set log_statement_stats = on; >> alter role peter set log_parser_stats = on; >> ERROR: 22023: invalid value for parameter "log_parser_stats": 1 >> DETAIL: Cannot enable parameter when "log_statement_stats" is true. > >> Another example is that in <=9.1, ALTER DATABASE ... SET search_path >> would check the existence of the schema in the current database, but >> that was done away with in 9.2. > >> The first example could probably be fixed if check_temp_buffers() paid >> attention to the GucSource, but in the second case and in general there >> doesn't seem to be a way to distinguish "assigning per-database setting" >> and "enacting per-database setting" as a source. > >> Ideas? > > Perhaps instead of trying to solve the problem as stated, it would be > more useful to put the effort into getting rid of context-sensitive > restrictions on GUC settings. Neither of the examples above seem > particularly essential - they are just protecting incomplete > implementations. The check_temp_buffers() problem seems like a regression and blocks us from upgrading to 9.2. The use case are functions that set temp_buffers and occasionally are called in a series from a parent session. The work around is... a lot of work. I'd appreciate it if we could fix the temp_buffers issue, and I support getting rid of context-sensitive restrictions. :) -selena -- http://chesnok.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] Configuration include directory
Hello! I've spent a little time with this patch and have attached revision 6. Thanks, Noah, for a fantastically detailed review. The only thing I didn't do that Noah suggested was run pgindent on guc-file.l. A cursory search did not reveal source compatible with my operating system for 'indent'. If someone points me to it, I'd happily also comply with the request to reindent. And document how to do that on my platform(s). :) I did just remove the references to the Apache project etc. I agree that providing best practices is good, but I'm skeptical about including best practices piecemeal. Adding it to earlier tutorial sections would probably be a bit more visible IMO. I also added examples to postgresql.conf.sample, per a suggestion from Dave Page. -selena -- http://chesnok.com config-directory-v6.patch Description: Binary data -- 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] Adding an example for replication configuration to pg_hba.conf
On Wed, May 18, 2011 at 8:20 PM, Alvaro Herrera wrote: > Excerpts from Greg Smith's message of mié may 18 23:07:13 -0400 2011: >> Two things that could be changed from this example to make it more useful: > >> -The default database is based on your user name, which is postgres in >> most packaged builds but not if you compile your own. I don't know >> whether it's practical to consider substituting that into this file, or >> if it's just enough to mention that as an additional doc comment. > > You mean the default username, not the default database, but yeah; so do > we need a @default_username@ token to be replaced by initdb with > whatever it has as effective_user? (In this case the patch is no longer > 2 lines, but still should be trivial enough). That would be nice. So, we just add that token to initdb? Seems simple. I added some explanation of the all vs replication bit in the header comments. Revision attached. -selena -- http://chesnok.com pg_hba_bikeshed3.patch Description: Binary data -- 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] Adding an example for replication configuration to pg_hba.conf
On Wed, May 18, 2011 at 9:35 AM, Christopher Browne wrote: > On Wed, May 18, 2011 at 12:17 PM, Selena Deckelmann > wrote: >> At the risk of starting an epic bikeshedding thread, I've attached a >> small patch that includes an example for both ipv4 and ipv6 localhost >> configuration. > > My "bikeshedding" would be to ensure that the sample pg_hba.conf > includes some kind of reference comment indicating where to look in > the documentation for more about this. Section numbers aren't stable > enough; section title is probably apropos. We don't do this in any of the other configuration files, so while I like the focus on helping users out, it would be a significant departure from convention. Creating an annotated config file in the wiki would be welcome. :) -selena -- http://chesnok.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] Adding an example for replication configuration to pg_hba.conf
And this patch is aligned in a more pleasing way. -selena -- http://chesnok.com pg_hba_bikeshed2.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Adding an example for replication configuration to pg_hba.conf
I reviewed the process for configuring replication, and found that we don't have an example for allowing replication access in pg_hba.conf. Before we release 9.1, I think we should add this example to make it more obvious this is a necessary part of replication configuration. At the risk of starting an epic bikeshedding thread, I've attached a small patch that includes an example for both ipv4 and ipv6 localhost configuration. -selena -- http://chesnok.com pg_hba_bikeshed1.patch Description: Binary data -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] PgCon 2011 Lightning Talks - Submit yours today!
Hi! We're having Lightning Talks again at PgCon - scheduled for 5:30pm on May 19th in Ottawa! Do you have a talk or idea you'd like to share? Didn't get your original talk in? Want to compress that into 5 minutes? Lightning Talks are one of the most highly attended sessions because they are fast, fun, and useful (but not always). Slides are not required. If you use them, you'll have to operate them as PDFs. Please submit your 5-minute talk idea: http://chesnok.com/u/1Z Slots fill up fast, so get them in now! We will accept submissions on the form until May 16th. After that, you'll need to find Selena or Magnus at PgCon to get in. We can only accept 11 talks in the time allowed. Selection is generally first-come, first-served. We will not determine the order of the talks until the time of the session. More details are at: http://www.pgcon.org/2011/schedule/events/369.en.html -- http://chesnok.com/daily - 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] PostgreSQL Core Team
On Apr 27, 2011 1:49 PM, "Dave Page" wrote: > > I'm pleased to announce that effective immediately, Magnus Hagander > will be joining the PostgreSQL Core Team. > > Magnus has been a contributor to PostgreSQL for over 12 years, and > played a major part in the development and ongoing maintenance of the > native Windows port, quickly becoming a committer to help with his > efforts. He's one of the project's webmasters and sysadmins and also > contributes to related projects such as pgAdmin. In his spare time, he > serves as President of the Board of PostgreSQL Europe. Grattis, Magnus. :-) -selena
Re: [HACKERS] Headcount for PL Summit, Saturday May 21, 2011 at PgCon
Hello again! On Thu, Apr 7, 2011 at 10:22 AM, Selena Deckelmann wrote: > We need to get a headcount for the PL Summit at PgCon on Saturday, May > 21, 2011. > > Please sign up using this form: http://chesnok.com/u/1r > > A wiki page has been started here: > > http://wiki.postgresql.org/wiki/PgCon_2011_PL_Summit It was brought to my attention that no one was listed other than me for the meeting. :) I've updated the wiki with the names I have so far - really, people will be there! Thanks, -selena -- http://chesnok.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] Headcount for PL Summit, Saturday May 21, 2011 at PgCon
Hi! We need to get a headcount for the PL Summit at PgCon on Saturday, May 21, 2011. Please sign up using this form: http://chesnok.com/u/1r A wiki page has been started here: http://wiki.postgresql.org/wiki/PgCon_2011_PL_Summit We're also working on updating this page: http://wiki.postgresql.org/wiki/PL_Matrix And we started a list of other columns that we'd like to add to the PL_Matrix here: http://wiki.postgresql.org/wiki/PL_Features_Matrix * Joe Conway and others have broached the topic of coming up with a suggested list of features to implement for new PLs, so input from all PL developers would be very helpful. Thanks! -selena -- http://chesnok.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] GSoC Proposal - Caching query results in pgpool-II
2011/4/5 Masanori Yamazaki : > Hello > > I am sending my proposal about Google Summer Of Code2011. > It would be nice if you could give me your opinion. Fantastic! Please submit your proposal through the GSoC website: http://www.google-melange.com/gsoc/profile/student/google/gsoc2011 -selena -- http://chesnok.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] proposal: a validator for configuration files
Hi! On Wed, Mar 30, 2011 at 8:40 AM, Alexey Klyukin wrote: > I'd like to add an ability to validate the corectness of PostgreSQL > configuration files, i.e. postgresql.conf, pg_hba.conf, pg_ident.conf without > actually applying them. The idea is that it would be a command-line option to > postgres for a stand-alone case, or a user-callable function when postmaster > is running. > > Per the former discussion of a validator for PostgreSQL configuration files > (see http://archives.postgresql.org/pgsql-hackers/2008-08/msg00048.php), > here's an implementation proposal. I did a little bit of work on this, and we discussed it here: http://archives.postgresql.org/pgsql-hackers/2009-03/msg00345.php http://archives.postgresql.org/pgsql-hackers/2009-03/msg01142.php Probably there's a bit of bitrot in there. > The development plan consists of 2 parts. > The first one is to add new code that would allow running the checks in both a > stand-alone process, when postmaster is not running, and as a function call > from a backend postgres process. Initially the code would simply loads > configuration files, without performing any of the validation checks. The > second part consists of adding specific checks. Cool! Mine was only going to work if the system started up or was reloaded. > I think most of the code related to this feature should be put into the > auxiliary process. The rationale is that we already have a stand-alone > CheckerProcess, which nowadays only parses postgresql.conf, runs BaseInit and > exists. We can easily load pg_hba.conf and pg_ident.conf and run all the > necessary checks there. Moreover, the same process can be used when checks are > launched from a built-in function. In that case, it would save the postgres > backend from reloading postgresql.conf, pg_hba.conf and pg_ident.conf > internally and restoring the previous configuration options when the function > exists. Below is a more detailed description of implementation steps: > > 1.1. Stand-alone process (postmaster is not running): > > - Add a new option (--check-config) to main.c. Run AuxiliaryProcessMain with > auxType= CheckerProcess if this option is specified. > - In CheckerModeMain load pg_hba.conf, pg_ident.conf > > > 1.2. Built-in function, called from a backend process. > - Add a new built-in function > - Add LastCheckState shared flag to denote whether the check has been > successful or failed > - Add a new PMSignalReason > - From the function call SendPostmasterSignal with the reason added on the > previous step. > - In the postmaster add a check for this reason in sigusr1_handler, spawning > a checker process. Set LastCheckStatus to InProgress. > - Store current configuration options in AuxillaryProcessMain before reloading > configuration files to avoid checking for options that haven't changed. > - In AuxillaryProcessMain, modify SelectConfigFiles invocation to call it > if IsUnderPostmaster = true if auxType process type is CheckerProcess. > - In the CheckerModeMain, set LastCheckState to either success or failure at > the > end of all checks. > - The built-in function would wait until LastCheckState changes its value from > InProgress to either Succcess or Failure, or until some predefined timeout > expires, in which case it would emit an error. > > 2. Add following configuration checks: > > postgresql.conf: > > Check that: > 1. postgres can bind to listen address:port > 2. unix_socket_directory has proper permissions (n/a on Windows). > 3. unix_socket_group group exists on a target system (n/a Windows). > 4. unix_socket_permissions are valid (write permission is not revoked from > the owner, or a group, if group is different from the user). > 5. server.crt and server.key exist in the data directory if ssl is > set to true (and server is compiled with openssl) > 6. krb_server_keyfile is readable by the server (if set) > 7. server is not requesting more shared memory than it's available in the > system. > 8. shared_preload_libraries and local_preload_libraries exist. > 9. synchronous_standby_names are not empty and max_wal_senders > are > 0 if synchronous_replication = true > 10. all enable_* query planner parameters are on. > 11. seq_page_cost <= random_page_cost, and cpu_ costs are lower than page_ > costs. > 12. effective_cache_size is less than the amount of physical memory > available. > 13. geqo is turned on > 14. default_statistics_target is >= 100 > 15. logging collector is enabled if log destination is stderr > 16. log directory either exists and writable or that the parent > directory allows creating subdris > 17. track counts is on if autovacuum is enabled > 18. stats_temp_directory is writeable > 19. default tablespace exists (if set) > 20. temp_tablespace exists (if set) > 21. statement_timeout is 0 (disabled) > 22. dynamic_library_path exists > 23. sql_inheritance is off > 24. zero_damaged_pages is off Some of this seems not like thing
[HACKERS] Accepted into GSoC 2011, student proposals start March 28
Hi! The PostgreSQL project has been accepted into the Google Summer of Code 2011. Students may begin submitting proposals starting March 28, concluding on April 8. Development work runs from May 23 through August 15. For students, suggested projects, ideas and details are at: http://wiki.postgresql.org/wiki/GSoC_2011 Our GSoC landing page is at: http://www.google-melange.com/gsoc/org/show/google/gsoc2011/postgresql We encourage students to contact project admins - me, Josh Berkus and Robert Treat this year - if they have questions. Once students have a proposal in mind, we will encourage them to engage with pgsql-hackers to flesh out their proposals and get feedback the same way that all contributors do. For those of you who have been around for previous GSoCs, this should be familiar to you. :) Many thanks to the 15 volunteer mentors and admins this year (in no particular order): Dave Page - Former mentor - pgAdmin, Windows, Packaging, Infrastructure Heikki Linnakangas - Postgres Committer Magnus Hagander - Postgres Committer, Windows, pgAdmin Guillaume Lelarge - pgAdmin Jehan-Guillaume de Rorthais - phpPgAdmin Joe Abbate - Python-related, catalog-related projects David E. Wheeler - Perl-related, extensions, PGXN Mark Wong - benchmarking, monitoring, performance Tatsuo Ishii - Postgres Committer, pgpool-II Stephen Frost - Postgres contributor Devrim Gündüz - Administration related software (dashboard) Josh Berkus - auto-configuration, performance testing Selena Deckelmann - configuration, testing Andreas Scherbaum - performance, configuration, testing Robert Treat - Past mentor 2x, co-admin, Mentor Summit attendee. We can always accept more mentors! Actual assignment to projects depends greatly on the proposals from students. Please contact me if you are interested. Thanks! -selena -- http://chesnok.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] GSoC 2011 - Mentors? Projects?
On Tue, Mar 8, 2011 at 3:52 PM, Tatsuo Ishii wrote: >> Hi! >> >> PostgreSQL is applying for GSoC again this year. We're looking for: >> >> * Mentors > > Can I be a metor for pgpool-II? Yes! I can't guarantee that we will get student proposals for it. But, we will have a greater chance of student proposals for things if we specifically list out projects that you'd like a student to tackle. Could you add a few items to the wiki page for pgpool-II? http://wiki.postgresql.org/wiki/GSoC_2011#Project_Ideas Thanks! -selena -- http://chesnok.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] GSoC 2011 - Mentors? Projects?
Hi Alexander, On Tue, Mar 8, 2011 at 12:13 PM, Alexander Korotkov wrote: > I've following project proposal. Thanks for getting a head start! One warning - we haven't been accepted into GSoC yet. :) I'll be sure to contact you if we are accepted! > Currently GiST index don't have any bulk load functionality. It have to > create new index by entry insertion one by one. This makes new index > creation relatively slow. > There are various works in computer science about bulk operation on R-tree. > Since gist in basic is generalization of R-tree, some of them seems to > be applicable to GiST. > Following work seems to be most applicable to GiST: > "Efficient Bulk Operations on Dynamic R-Trees", L. Arge, K. H. Hinrichs, J. > Vahrenhold and J. S. Vitter > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.135.9894&rep=rep1&type=pdf > I believe that implementation of methods of this work should allow to > significally reduce GiST index creation time (probably, it'll be possible to > achive acceleration of other operations too). Also, it's possible to achive > some results in computer science, since GiST is more general data structure > than R-tree. > I'm going to create wiki page for this project proposal soon. That sounds great. Please go ahead and create the page now. -selena -- http://chesnok.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] GSoC 2011 - Mentors? Projects?
Hi! PostgreSQL is applying for GSoC again this year. We're looking for: * Mentors * Project ideas Would you like to mentor? Please let me know! Our application closes on Friday, so please contact me *before* Friday. I've started a wiki page: http://wiki.postgresql.org/wiki/GSoC_2011 It's seeded with last year's todo lists and information. We need to add project ideas for students to it. The wiki pages for 2008 and 2010 are available, including links to the original student proposals: http://wiki.postgresql.org/wiki/GSoC_2010 http://wiki.postgresql.org/wiki/GSoC_2008 Thanks! -selena -- http://chesnok.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] PL developer summit, May 21 at PgCon
Hi! I've been contacting PL developers directly over the last couple of weeks about having a PL summit at PgCon this year. The overwhelming response was: yes, let's do it! So, we will have the summit starting at 9:30am, Saturday May 21 at PgCon in Ottawa. We'll meet in one of the session rooms on campus. Details on what has been talked about so far is here: http://www.chesnok.com/daily/2011/02/28/pl-developer-summit-at-pgcon-may-21/ To RSVP, please fill out this form: https://spreadsheets0.google.com/viewform?formkey=dFIxWEU3T3I2WGlORVhkQW4zZVQ0VkE6MQ We'll provide lunch for those that RSVP. I've started a wiki page for the agenda: http://wiki.postgresql.org/wiki/PgCon_2011_PL_Summit Thanks! -selena -- http://chesnok.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] Tasks for Google Code-In
The Oregon State University's Open Source Lab (OSL) has contacted me about coordinating some student work for the Google Code-In, a program targetting 13-18 year olds. See more here: http://code.google.com/opensource/gci/2010-11/index.html This program specifically allows documentation, testing and advocacy activity not normally allowed in the Google Summer of Code. And OSL is offering to be an umbrella organization -- handling the administrative details for us. So! Do you have some 2-3 week projects in mind appropriate for high school students to tackle? Please post some ideas, and we can get this going. -selena -- http://chesnok.com/daily - me
[HACKERS] Submissions for a PostgreSQL track at MySQL Conf 2011: Due October 25
Hi! I'm on the committee for MySQL Conf this year, and the committee is specifically seeking talks about PostgreSQL. The idea is to broaden the scope of the conference to include a lot of different open source database technology, including a bunch more about Postgres. The organizing committee is specifically seeking PostgreSQL talks - some of you may have heard from Baron or Robin already about this. The CFP is here: http://en.oreilly.com/mysql2011/public/cfp/126 The submission deadline for all proposals is October 25, 2010! Topics for consideration include: * Innovative uses of Postgres * Data warehousing * Architectures based on Postgres * PostGIS * Government + Postgres * [your favorite web framework] + Postgres * Performance and optimization * Security and database administration * "In the cloud" * Business and case studies Please contact me directly for feedback, help with submissions or help generating ideas. And if you're submitting, please just drop me a line to let me know! I'd love to hear from all that are interested. -selena -- http://chesnok.com/daily - 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] Broken due to CVS branching? .bki has wrong info for build
On Sat, Jul 17, 2010 at 10:51 AM, Tom Lane wrote: > Selena Deckelmann writes: >> I pulled the latest from the git repo, I got this error on initdb: > >> creating template1 database in testdb/base/1 ... initdb: input file >> "/usr/local/pg90/share/postgresql/postgres.bki" does not belong to >> PostgreSQL 9.0devel > >> The problem was having '9.1' instead of '9.0' in the first line of the .bki. > > Yeah, I ran into that too. The makefiles don't have a dependency that > forces postgres.bki to be rebuilt when you update the major version in > configure.in. Just delete src/backend/catalog/postgres.bki and > rebuild/reinstall. (Actually, as of CVS HEAD it shouldn't be a problem > anymore because of yesterday's changes in pg_proc.h.) > > I'm not sure whether it's worth adding an explicit dependency to cover > this case. It only comes into play at major version boundaries. Ok, that makes sense. I rebuilt just now, and it worked fine. Thanks! -selena -- http://chesnok.com/daily - me -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Broken due to CVS branching? .bki has wrong info for build
Hi! I pulled the latest from the git repo, I got this error on initdb: creating template1 database in testdb/base/1 ... initdb: input file "/usr/local/pg90/share/postgresql/postgres.bki" does not belong to PostgreSQL 9.0devel The problem was having '9.1' instead of '9.0' in the first line of the .bki. Any chance someone can fix this before tomorrow? I'm giving a talk here in Portland, and lots of OSCON people will probably be attempting to use the git repo this week. -selena -- http://chesnok.com/daily - 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] ALTER TABLE...ALTER COLUMN vs inheritance
On Wed, Jun 16, 2010 at 5:31 AM, Bernd Helmle wrote: > > > --On 15. Juni 2010 20:51:21 -0700 Selena Deckelmann > wrote: > >> Confirmed that this tests fine against commit id >> 0dca7d2f70872a242d4430c4c3aa01ba8dbd4a8c >> >> I also wrote a little test script and verified that it throws an error >> when I try to remove a constraint from the parent table. >> > > Thanks for looking at this. > > Please note that the main purpose of this patch is to protect *child* tables > against dropping NOT NULL constraints inherited from a parent table. This > could lead to unrestorable dumps formerly. Yes! I didn't say that right earlier -- sorry I should have attached the test. I'll just try to add it and send it to you in patch form. >> Should an explicit test be added for this? >> > > I think so, yes. > >> There are some spelling and grammar errors in comments that I can help >> fix if you want the help. > > You're welcome. I have pushed my branch to my git repos as well, if you like > to start from there: > > <http://git.postgresql.org/gitweb?p=bernd_pg.git;a=shortlog;h=refs/heads/notnull_constraint> Awesome! I'll have a look this afternoon. And, I didn't really know what to say about the rest of the issues you brought up around structuring the code, and the couple TODOs still left in the patch. -selena -- http://chesnok.com/daily - 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] ALTER TABLE...ALTER COLUMN vs inheritance
On Wed, May 26, 2010 at 2:37 PM, Bernd Helmle wrote: > Lost it a little from my radar, but here's is a first shot on this issue > now. The patch creates a new CONSTRAINT_NOTNULL contype and assigns all > required information for the NOT NULL constraint to it. Currently the > constraint records the attribute number it belongs to and manages the > inheritance properties. Passes regression tests with some adjustments to > pg_constraint output. Confirmed that this tests fine against commit id 0dca7d2f70872a242d4430c4c3aa01ba8dbd4a8c I also wrote a little test script and verified that it throws an error when I try to remove a constraint from the parent table. Should an explicit test be added for this? There are some spelling and grammar errors in comments that I can help fix if you want the help. -selena -- http://chesnok.com/daily - 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] [RRR] Reviewfest 2010-06 Plans and Call for Reviewers
Hi! On Mon, Jun 14, 2010 at 9:25 AM, Kevin Grittner wrote: > http://wiki.postgresql.org/wiki/PostgreSQL_9.1_Development_Plan > > calls for a ReviewFest to run from the 15th of June (tomorrow) until > the start of the first CommitFest for the 9.1 release. The idea is > that those with time available to contribute beyond what they can > usefully contribute to getting 9.0 released can help provide > feedback on patches submitted so far, to lighten the load of the CF > proper when it starts. I have agreed to manage this RF. I'm helping out too :) A few folks from PDXPUG are meeting up this evening to go over some patches. We'll be on IRC at #pdxpug from 6pm-8pm PDT if you want to join in virtually. We'll post our results tomorrow! -selena -- http://chesnok.com/daily - 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] Regression testing for psql
On Wed, May 26, 2010 at 6:25 PM, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> There might be some value in psql backslash command tests that >> are designed to depend on just one or a few tables (or other appropriate >> objects). > > Updated, much much smaller, patch attached. Also available, again, at > http://snowman.net/~sfrost/psql-regress-help.patch > > Basically, I removed anything that would produce data directly from > the catalogs by trying to find a 'none' object which matched. This > still goes through alot of the same setup and query, it's just that > there aren't any results. Is this something to be added to 2010-07 commitfest? -selena -- http://chesnok.com/daily - me -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] 9.0 Open Items: Code and Documentation sections
Hi! I've spent some time going through all the email threads since Alpha4 was released, and have updated the 9.0 Open Items list. We have two sections of open items which need initial review by -hackers: http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items#Code http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items#Documentation If you know that an item has been resolved, please move it to the Resolved section. If you have additional information about the status of the page, please feel free to update the details accordingly! Thanks! -selena -- http://chesnok.com/daily - 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] WIP patch for serializable transactions with predicate locking
On Wed, May 19, 2010 at 5:37 PM, Kevin Grittner wrote: > I heard that others were considering work on predicate locks for > 9.1. Since Dan Ports of MIT and I have been working on that for the > serializable implementation for the last few weeks, I felt it would > be good to post a WIP patch to avoid duplicate effort. I added this to the next commitfest with the 'WIP' prominent. I figured it was worth including for initial reviews, although of course, detailed work will likely wait until July. -selena -- http://chesnok.com/daily - 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] Show schema name on REINDEX DATABASE
On Mon, Apr 5, 2010 at 9:29 AM, Greg Sabino Mullane wrote: > Patch attached to show the schema *and* table name when doing > a REINDEX DATABASE. Is this something that can be added to 9.1 commitfest? -selena -- http://chesnok.com/daily - 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] Renaming '2010-Next' to '2010-6' in the commitfest app
On Thu, May 20, 2010 at 12:03 PM, Tom Lane wrote: > Selena Deckelmann writes: >> On Thu, May 20, 2010 at 9:24 AM, Tom Lane wrote: >>> Yeah, I thought the agreement was to keep the same target dates as >>> for last year's commitfests. > >> Yes! However, we were going to do a "reviewfest" starting June 15. > >> Is there a way for me to specify that differently? It would be very >> helpful to be able to use the commitfest app for the reviewfest. > > I think the easiest way to deal with it is just to say that we're > hoping to get an early start on the commitfest by beginning reviewing > early on the already-submitted patches. There's nothing stopping > anyone from working on those patches in advance of the nominal > commitfest start date. (Of course, we can't actually commit any > of them until the 9.0 branch is made; which is why I think it's > a July commitfest not a June one.) Yeah, I get that. A nice feature would be to allow for "reviewfests" to occur and then be transitioned into a "commitfest" inside the application without too much trouble. My fear is that people won't be as motivated to work on patches without a clear transition between phases, but that could certainly be unfounded. I'll just do my best to set expectations among the reviewers and patch authors that nothing will be committed/looked at by committers until July. -selena -- http://chesnok.com/daily - 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] Renaming '2010-Next' to '2010-6' in the commitfest app
On Thu, May 20, 2010 at 9:24 AM, Tom Lane wrote: > Robert Haas writes: >> On Thu, May 20, 2010 at 12:51 AM, Selena Deckelmann >> wrote: >>> Can we get that commitfest renamed? And if I should know how to do >>> that, can you inform me how? > >> I thought we agreed on 2009-07? > > Yeah, I thought the agreement was to keep the same target dates as > for last year's commitfests. Yes! However, we were going to do a "reviewfest" starting June 15. Is there a way for me to specify that differently? It would be very helpful to be able to use the commitfest app for the reviewfest. -selena -- http://chesnok.com/daily - me -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Renaming '2010-Next' to '2010-6' in the commitfest app
Hi Robert, Can we get that commitfest renamed? And if I should know how to do that, can you inform me how? Thanks! -selene -- http://chesnok.com/daily - 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] Lightning Talks for PgCon! Submit yours today.
Just a reminder -- We've got a few spaces left for lightning talks. Submit your idea today! See below for details. -selena On Sat, May 8, 2010 at 6:46 AM, Selena Deckelmann wrote: > Hi! > > We're having Lightning Talks again at PgCon - scheduled for 5:30pm on > May 20th in Ottawa! > > Do you have a talk or idea you'd like to share? Lightning Talks are > one of the most highly attended sessions because they are fast, fun, > and useful (but not always). Slides are not required. If you use > them, you'll have to operate them as PDFs. > > Please send your 5-minute talk idea to . Slots fill > up fast, so get them in now! We'll accept submissions until May 16 via > email, and after that, you'll need to find me (Selena) at the > conference if you'd like to be added. > > We can only accept 11 talks in the time allowed. Selection is > generally first-come, first-served. I will not determine the order of > the talks until the time of the session. > > More details are at: > > http://www.pgcon.org/2010/schedule/events/267.en.html > > -- > http://chesnok.com/daily - me > http://endpoint.com - work > -- http://chesnok.com/daily - 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] List traffic
On Fri, May 14, 2010 at 9:51 AM, Josh Berkus wrote: > Second, regarding advocacy: no, absolutely not. -advocacy is a working list > and not a virtual water cooler. +1. I would find it very difficult to manage having -advocacy thrown into -general. If folks think that information isn't getting wide enough distribution, that's one thing. But it is an important working group, even if there's not a ton of traffic all the time on it. -selena -- http://chesnok.com/daily - me -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Lightning Talks for PgCon! Submit yours today.
Hi! We're having Lightning Talks again at PgCon - scheduled for 5:30pm on May 20th in Ottawa! Do you have a talk or idea you'd like to share? Lightning Talks are one of the most highly attended sessions because they are fast, fun, and useful (but not always). Slides are not required. If you use them, you'll have to operate them as PDFs. Please send your 5-minute talk idea to . Slots fill up fast, so get them in now! We'll accept submissions until May 16 via email, and after that, you'll need to find me (Selena) at the conference if you'd like to be added. We can only accept 11 talks in the time allowed. Selection is generally first-come, first-served. I will not determine the order of the talks until the time of the session. More details are at: http://www.pgcon.org/2010/schedule/events/267.en.html -- http://chesnok.com/daily - me http://endpoint.com - work -- 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] Dividing progress/debug information in pg_standby, and stat before copy
On Tue, Jan 26, 2010 at 11:03 PM, Greg Smith wrote: > Tom Lane wrote: >> >> Right, but the question is: is there enough use-case left in it to >> justify spending community effort on polishing rough edges? It's not >> like we haven't got plenty else to do to get 9.0 out the door. >> > > The point I was trying to make is that I'm on the hook to do this particular > job whether or not the community feels it's worthwhile. The only real > decision is whether there's enough interest in upgrading this utility to > review and possibly commit the result, and I'm trying to minimize the public > resources needed even for those parts. I'm interested as well, so happy to continue to work with you on it, Greg. -selena -- http://chesnok.com/daily - me http://endpoint.com - work -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Google Summer of Code 2010 is on! (applications due March 9)
Hi! I'm happy to facilitate this and get the details in for our application. Seems like we have lots of things that we could get students involved with, and of course, we tend to get interesting projects pitched to us that we haven't thought of before. I've attended the Mentor Summit after GSoC for the last two years, and found it to be a great resource for learning how all projects are recruiting and retaining new members. Many of these projects admire Postgres for it's stability over the years, and I've been able to communicate some of the work that we've all done on the commit fest, our review process and generally how our community works to many other projects. Those who would like to mentor and help administrate the program, please get in touch with me directly . I'll set up some lists to keep us in sync, and we'll report out what happens. -selena -- Forwarded message -- From: LH (Leslie Hawthorn) Date: Tue, Jan 26, 2010 at 4:10 PM Subject: GSoC 2010 is on. To: Google Summer of Code Mentors List Hello folks, If you're not following the program discussion list, you may have missed this mail with some details about timing for GSoC 2010: http://groups.google.com/group/google-summer-of-code-discuss/browse_thread/thread/d839c0b02ac15b3f Cheers, LH --- Hello everyone, Many of you were wondering if Google Summer of Code 2010 is on for 2010 and the answer is yes! We will begin accepting application from would-be mentoring organizations beginning March 8th at approximately 19:00 UTC, with applications closing on March 12th at 23:00 UTC. Students can apply between 19:00 UTC on March 29th to 19:00 UTC on April 9th. We will be updating the program website [0], including the FAQs [1], over the next few days. Not much is going to change except the timeline, though there are a few FAQs that will be added. If you have any questions in the interim please do send them to the list. Please note that questions about which project you should select, etc., will likely be responded to with "depends on your skill set," so please take the time to do some research [2] about which project is right for you. While mentoring organizations for 2010 will be announced until March 18th, a great number of the projects that have participated in the past [3] will return once again in 2010. Of course, that's not a guarantee and we cannot accept every great project that applies. But if you want to get a jump start on your participation in GSoC 2010, considering lurking in the IRC channel of a past participating project and seeing what useful things you can learn about their code base and community. Check out project forums to see if it's a place you'd like to spend your time. I'll be sending a follow up message in a few minutes about what to expect in the next few days/weeks and how you can help Google Summer of Code 2010. Google Summer of Code 2010 is on! Celebrate! [0] - http://socghop.appspot.com [1] - http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2009... [2] - http://delicious.com/gsoc2009 [3] - http://socghop.appspot.com/gsoc/program/accepted_orgs/google/gsoc2009 Cheers, LH -- Leslie Hawthorn Program Manager - Open Source Google Inc. -- http://chesnok.com/daily - me http://endpoint.com - work -- 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] Dividing progress/debug information in pg_standby, and stat before copy
Hi! On Mon, Jan 25, 2010 at 1:34 PM, Greg Smith wrote: > Josh Berkus wrote: >> >> We discussed this issue at LCA where I encountered these bogus error >> messages when I was doing the demo of HS. I consider Selena's patch to >> be a bug-fix for beta of 9.0, not a feature. Currently the database >> reports a lot of false error messages when running in standby mode, and >> once we have 1000's more users using standby mode, we're going to see a >> lot of related confusion. >> > > Does anyone have a complete list of the false error messages and what > context they show up in so that a proper test case could be constructed? They aren't "false" technically. They are the result of the function call attempting to copy files that do not exist. It's not a big deal functionality-wise, but it retries a few times. The stat call "fixes" it. I could do a bit more there with the error result, but didn't. I can scan through the code tonight and look for other cases where this might be an issue. The main thing I'm looking for is to distinguish between harmful and non-harmful errors. > I extracted some pg_standby changes from Simon last week that have some > overlap with Selena's patch (better logging, remove bogus link feature, > throw less false error messages out). I'm not quite ready to submit > anything here just yet, I'm going to break that into more targeted patches, > but I will be later this week. I share the concern here that some of these > issues are annoying enough to be considered bugs, and I need to fix them > regardless of whether anybody else does. The stat issue is one of those issues for users that makes them think: "this looks like an error, and i've never done this before. maybe there is SOMETHING WRONG!" I included the progress/logging/verbosity changes so that the errors were still generated but were definitely flagged as 'debugging' and 'probably not an issue'. :) > I'd be happy to work with Selena > as a review pair here, to knock out the worst of the problems on this Sweet. I, too, would love to work with you to get this fancied/cleaned up. > program, now that the use-case for it should be more popular. pg_standby > could use a bit of an upgrade based on the rough edges found by all its > field tests, most of which is in error handling and logging. I don't have > anything like her stat check in what I'm working on, so there's certainly > useful stuff uniquely in each patch. Thanks! >> * Could we just re-use '-l' for logging? > > The patch I'm working on adds "-v verbosity" so that logging can be a bit > more fine-grained than that even. Having both debug and a progress report > boolean can then get folded into a single verbosity level, rather than > maintain two similar paths. Just make debug equal to the highest verbosity > and maybe start deprecating that switch altogether. > > One reason I'm not quite ready to submit what I've got yet is that I want to > unify things better here. I think that I'd prefer to use the same > terminology as log_min_messages for the various options, and make a macro > wrapper like ELOG this code uses instead of all these terrible direct > fprintf([stderr|stdout]... calls. Yes, a wrapper is desperately needed with timestamps. >> * Is there a way to get a non-module to use the ereport/elog system? > > And that work would make this transition easier to make, too, if it became > feasible. I fear that's outside of the scope of what anyone wants to touch > at this point though. Sure thing. I scanned what was in contrib and didn't see anything I could crib in there. Was just throwing it out there if someone had already done it. -selena -- http://chesnok.com/daily - me http://endpoint.com - work -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Dividing progress/debug information in pg_standby, and stat before copy
Hi! I poked around a little at pg_standby because of some 'cp: file does not exist' errors that were cropping up as pg_standby searched around for .history files. I added a stat that still outputs debugging information but now we don't get cp failures, and then added a 'progress' mode. It was a bit of a semantic stretch, but '-l' had been used for 'link' in the past. I will also add a timestamp to all of the output in my next patch. But before I do that.. Questions: * Could we just re-use '-l' for logging? * Is there a way to get a non-module to use the ereport/elog system? -selena -- http://chesnok.com/daily - me http://endpoint.com - work pg_standby_progress.patch Description: Binary data -- 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] Summary and Plan for Hot Standby
On Fri, Nov 20, 2009 at 11:14 AM, Josh Berkus wrote: > On 11/15/09 11:07 PM, Heikki Linnakangas wrote: >> - When replaying b-tree deletions, we currently wait out/cancel all >> running (read-only) transactions. We take the ultra-conservative stance >> because we don't know how recent the tuples being deleted are. If we >> could store a better estimate for latestRemovedXid in the WAL record, we >> could make that less conservative. > > Simon was explaining this issue here at JPUGCon; now that I understand > it, this specific issue seems like the worst usability issue in HS now. > Bad enough to kill its usefulness for users, or even our ability to get > useful testing data; in an OLTP production database with several hundred > inserts per second it would result in pretty much never being able to > get any query which takes longer than a few seconds to complete on the > slave. I don't think that's all that was discussed :) Are you saying that it should not be committed if this issue still exists? The point of getting Hot Standby into core is to provide useful functionality. We can make it clear to people what the limitations are, and Simon has said that he will continue to work on solving this problem. -selena -- http://chesnok.com/daily - me http://endpoint.com - work -- 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 committers
I'm not addressing the complaints Emmanuel has about patch submission, but was inspired by what he said. I hesitated to post this to -hackers, but my hope is that my comments are taken in the spirit of reflection. I've been thinking about the Postgres community and things that differentiate it from other FOSS projects for a few years. We lack both a benevolent dictator, or a single-corporate backer... We have an incredible reputation for technical expertise -- most knowledgeable FOSS developers fear and are in awe of the quality of code our community produces. I hear criticism for the way in which our development community operates, and how we communicate with "outsiders". But few people are able to offer concrete suggestions on /how/ we might change, as opposed to the /particular things/ that they think should change. So on this point: On Wed, Nov 11, 2009 at 7:30 PM, Emmanuel Cecchet wrote: > The commitfest started to > address some of the most obvious issues but there is probably much more that > can be done by looking at what is happening in the other open source > communities. Speaking from a cultural, and organizational standpoint: * Distributed revision control as standard for the project Using a distributed revision control system, and working from developer branches which are pulled & pushed directly between developers is consistently reported to have a positive impact on solving problems and sharing information. Summer of Code mentors consistently mention DVCS as having a huge positive impact on productivity for their students - both because it's easy and cheap for students to commit to their local repos, and because the merge/pull tools are intuitive for the mentors and students. This is how people work and share code "out there". I realize that Postgres has an established cultural norm of posting patches to the mailing list, and I'm not suggesting that people stop doing that. I think more developers should be sharing branches as well. git.postgresql.org should probably be reorganized to clearly divide repos between postgresql-core and other projects (contrib, add-ons, whatever). We should also publish more information about how our developers are sharing code with each other through repos. * Decision making Is there a project you'd point to as a model for decision making? (serious question) This is a volunteer organization, and as such, we're subject to who has the expertise + time/energy to devote to the patches and projects. Going back to what Bruce has said about skill drain -- if more individuals were able to get their time sponsored to devote to the technical challenges posed by the patches, then it might be possible to have more coordinated/streamlined responses and decision making. My experience in FOSS projects is that Postgres does fairly well on execution compared to other projects (getting a new release out the door every year, and now the alphas every couple months), but has some issues with a couple large, important patches. Part of the problem there appears to be people being stretched too thin, and inconsistent communication practices. More involvement from people really focusing on improving communication between developers would be helpful to make those issues easier to work around. * Volunteers, funding and burnout It's challenging to keep up with the technical discussions on -hackers even if you are a very knowledgeable developer. If you're only doing that on your free time, and say, you have a family? Most of the developers that I know in other projects in leadership/commit manager roles don't have young children, and very few are women. So, another thing that we could use are more people like Bruce that can devote a great deal of *work* time to thinking about and acting on the issues around community management and recruitment. Robert Haas' time spent on commitfest, for example, if sponsored by a foundation would be very helpful. Maybe he could have bought a new dishwasher. :) Also, we could use an individual dedicated to raising funds and consistently executing on distributing the money out for non-code "infrastructure" projects. Like: * release management, * marketing, * dedicated public relations (driving things like new software release articles, organizing interviews with press, and getting new case studies written), and * keeping track of our relationships with other organizations (Summer of Code, conferences, commercial forks). A lot of this work falls on Josh Berkus to coordinate. There are many more tasks, and some are delegated to others & coordinated on -advocacy. Again, this is work that could be funded through a foundation, or as part of positions in particular companies. IMO, it's about providing incentives that encourage people to use their time wisely, and to help prevent burnout on the difficult tasks around people management. And to say definitively that the people tasks require organization and management, and we as a development c
Re: [HACKERS] next CommitFest
On Thu, Nov 12, 2009 at 8:31 AM, Simon Riggs wrote: > Not a new idea, but I think we should require all patch submitters to do > one review per submission. There needs to be a balance between time > spent on review and time spent on dev. The only real way this happens in > any community is by peer review. I like this idea. Perhaps also if a person is reviewing a patch for the first time, we could make some effort to get a more experienced person paired up with them. Pairing up was really useful for the PDXPUG folks working on review. -- http://chesnok.com/daily - me http://endpoint.com - work -- 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] next CommitFest
On Wed, Nov 11, 2009 at 2:03 PM, Josh Berkus wrote: >> I'd be happy to get together at some pre-appointed hour this weekend >> (Saturday / Sunday) to talk it over by phone / IRC. PDXPUG was already >> planning to get together to review some patches this Sunday from 3-5pm >> PST, so that is a convenient time for me. > > Aren't you running OpenSQL this weekend? Yes :) But we have lots of volunteers. It's an unconference, and I delegated. -selena -- http://chesnok.com/daily - me http://endpoint.com - work -- 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] next CommitFest
Hi! On Tue, Nov 10, 2009 at 10:40 PM, Greg Smith wrote: > On Sun, 8 Nov 2009, Robert Haas wrote: > >> I would personally prefer not to be involved in the management of the >> next CommitFest. Having done all of the July CommitFest and a good >> chunk of the September CommitFest, I am feeling a bit burned out. > > I was just poking around on the Wiki, and it looks like the role of the > CommitFest manager isn't very well documented yet. Since you've done all of > them since introducing the new CF software, I'm not sure if anyone else even > knows exactly what you've been doing. The transition over to that was so > successful there isn't even a copy of the schedule for 8.5 on the Wiki > itself. Could you find some time this week to rattle off an outline of the > work involved? It's hard to decide whether to volunteer to help without > having a better idea of what's required. It's pretty straightforward. Robert has actually done a great job of communicating about this to the patch reviewers. I'd be happy to get together at some pre-appointed hour this weekend (Saturday / Sunday) to talk it over by phone / IRC. PDXPUG was already planning to get together to review some patches this Sunday from 3-5pm PST, so that is a convenient time for me. I can also help with commitfest admin tasks, but not in a dedicated way until after Thanksgiving as I'm going to be be traveling or on vacation. -selena -- http://chesnok.com/daily - me http://endpoint.com - work -- 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] COPY enhancements
Hi! On Fri, Sep 25, 2009 at 7:01 AM, Emmanuel Cecchet wrote: > Here is the new version of the patch that applies to CVS HEAD as of this > morning. Cool features! This is my first pass at the error logging portion of this patch. I'm going to take a break and try to go through the partitioning logic as well later this afternoon. caveat: I'm not familiar with most of the code paths that are being touched by this patch. Overall: * I noticed '\see' included in the comments in your code. These should be removed. * The regression is failling, as Jeff indicated, and I didn't figure out why yet either. Hopefully will have a look closer this afternoon. Comments: * copy.c: Better formatting, maybe rewording needed for comment starting on line 1990. ** Maybe say: "Check that errorData->sqlerrcode only logged tuples that are malformed. This ensures that we let other errors pass through." * copy.c: line: 2668 -> need to fix that comment :) (/* Regular code */) -- this needs to be more descriptive of what is actually happening. We fell through the partitioning logic, right, and back to the default behavior? * copy.c: line 2881, maybe say instead: "Mark that we have not read a line yet. This is necessary so that we can perform error logging on complete lines only." Formatting: * copy.c: whitespace is maybe a little off at line: 2004-2009 * NEW FILES: src/backend/utils/misc/errorlogging.c & errorlogging.h need headers Code: * copy.c: line 1990 -> cur_lineno_str[11] & related: why is this conversion necessary? (sorry if that is a dumb question) * copy.c: line 2660 -> what if we are error logging for copy? Does this get logged properly? * errorlogging.c: Noticed the comment at 503 -> 'note that we always enable wal logging'.. Thinking this through - the reasoning is that you won't be rolling back the error logging no matter what, right? * src/include/commands/copy.c and copy.h: struct CopyStateData was moved from copy.c to copy.h; this made sense to me, just noting. That move made it a little tricky to find the changes that were made. There were 10 items added. ** super nit pick: 'readlineOk' uses camel-case instead of underscores like the rest of the new variables * errorlogging.c: could move currentCommand pg_stat call in Init routine into MalformedTupleIs, or maybe move the setting of that parameter into the Init routine for consistency's sake. Documentation: * doc/src/sgml/ref/copy.sgml: line 313: 'failif' needs a space ** Also: The error table log examples have relations shown in a different order than the actual CREATE TABLE declaration in the code. * src/test/regress/sql/copyselect.sql: Format of options changed.. added parenthesis. Is this change documented elsewhere? (sorry if I just missed this in the rest of the thread/patch) -- http://chesnok.com/daily - me http://endpoint.com - work -- 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] Unicode UTF-8 table formatting for psql text output
Hi! On Wed, Sep 23, 2009 at 2:16 AM, Roger Leigh wrote: > On Fri, Sep 18, 2009 at 11:30:05AM -0700, Selena Deckelmann wrote: >> Brad says: >> >> The patched code compiles without any additional warnings. >> Lint gripes about a trailing ',' in 'typedef enum printTextRule' in >> print.h. Other additional lint seem to be false positives. The >> regression tests pass against the new patch. > > I've attached a new patch which tidies up those extra commas, plus > a patch showing the changes from the previous patch. Great! Thank you. Brad -- can you review this patch? Is it ready for a committer? Thanks, -selena -- http://chesnok.com/daily - me http://endpoint.com - work -- 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] Unicode UTF-8 table formatting for psql text output
Hi!
Below is from Brad Slinger. I'm just forwarding his message so that
the review will be in the thread for the archives. (Sorry, Brad that I
missed this earlier.. I thought you'd already replied to the list for
some reason.)
Brad says:
Please forgive my top posting. Below is my patch review.
The purpose of this patch is to improve psql output
readability. This is accomplished through table formatting
improvements and line art improvements.
The patch is a unified diff, rather than a context diff. The
patch applies from the project root with with -p1 set. Patch(1)
reports "with fuzz 1" when patching src/bin/psql/print.h. The patch
touches two files:
src/bin/psql/print.h
src/bin/psql/print.c
The patch does not include any documentation or tests.
Comments and style are similar to existing code.
The patched code compiles without any additional warnings.
Lint gripes about a trailing ',' in 'typedef enum printTextRule' in
print.h. Other additional lint seem to be false positives. The
regression tests pass against the new patch.
The patched code installs and runs. There were no crashes,
although I didn't try very hard. The ASCII line art works:
createdb test
psql test
\pset border 2
\pset format wrapped
SELECT 'short' AS short, lpad('', 1000, 'long') AS long;
I can trigger the new line art by setting LC_ALL=en_US.UTF-8 in
the environment.
As far as I can tell, the patch works as advertised. The patch
does not change the server/backend. I don't see any performance
problems.
Thanks,
--bts
--
http://chesnok.com/daily - me
http://endpoint.com - work
--
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] happy birthday Tom Lane ...
On Fri, Sep 18, 2009 at 4:04 AM, Hans-Juergen Schoenig -- PostgreSQL wrote: > Tom, > > On behalf of the entire PostgreSQL team here in Austria I want to wish you a > happy birthday. > We hope that you fill be a vital part of PostgreSQL for many years to come. In short, +1 from me. :) -selena -- http://chesnok.com/daily - me http://endpoint.com - work -- 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: Review handling of MOVE and FETCH (ToDo)
Hi!
John Naylor and I reviewed this patch. John created two test cases to
demonstrated issues described later in this email. I've attached
those for reference.
On Thu, Aug 27, 2009 at 8:04 PM, Pavel Stehule wrote:
> Hello,
>
> this small patch complete MOVE support in plpgsql and equalize plpgsql
> syntax with sql syntax.
>
> There are possible new directions:
>
> FORWARD expr, FORWARD ALL, BACKWARD expr, BACKWARD all.
>
> These directions are not allowed for FETCH statement, because returns more
> rows.
>
> This patch is related to ToDo issue: Review handling of MOVE and FETCH
== Submission review ==
* Is the patch in the standard form?
Yes, we have a contextual diff!
* Does it apply cleanly to the current CVS HEAD?
Yes!
* Does it include reasonable tests, docs, etc?
Suggestion: change variable 'returns_row' to 'returns_multiple_rows'
and invert the values of 'returns_row' in the patch.
Example:
if (!fetch->returns_row)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("statement FETCH returns more rows."),
errhint("Multirows fetch are not allowed in PL/pgSQL.")));
instead do:
if (fetch->returns_multiple_rows)
ereport(ERROR,
(errcode(ERRCODE_SYNTAX_ERROR),
errmsg("statement FETCH returns more than one row."),
errhint("Multirow FETCH is not allowed in PL/pgSQL.")));
Does that make sense? In reading the code, we thought this change
made this variable much easier to understand, and the affected code
much easier to read.
===
Need a hard tab here to match the surrounding code: :)
+ %token K_ALL$
===
Can you clarify this comment?
+ /*
+ * Read FETCH or MOVE statement direction. For statement for are only
+ * one row directions allowed. MOVE statement can use FORWARD [(n|ALL)],
+ * BACKWARD [(n|ALL)] directions too.
+ */
We think what you mean is:
By default, cursor will only move one row. To MOVE more than one row
at a time see complete_direction()
We tested on Mac OS X and Linux (Ubuntu)
===
Also, the tests did not test what the standard SQL syntax would
require. John created a test case that demonstrated that the current
patch did not work according to the SQL spec.
We used that to find a little bug in complete_direction() (see below!).
== Usability review ==
Read what the patch is supposed to do, and consider:
* Does the patch actually implement that?
No -- we found a bug:
Line 162 of the patch:
+ expr = read_sql_expression2(K_FROM, K_IN,
Should be:
+ fetch->expr = read_sql_expression2(K_FROM, K_IN,
And you don' t need to declare expr earlier in the function.
Once that's changed, the regression test needs to be updated for the
expected result set.
* Does it follow SQL spec, or the community-agreed behavior?
It conforms with the already implemented SQL syntax once the
'fetch->expr' thing is fixed.
* Have all the bases been covered?
We think so, as long the documentation is fixed and the above changes
are applied.
Another thing John noted is that additional documentation needs to be
updated for the SQL standard syntax, so that it no longer says that
PL/PgSQL doesn't implement the same functionality.
Thanks!
-selena & John
--
http://chesnok.com/daily - me
http://endpoint.com - work
MOVE_patch_test_case2
Description: Binary data
MOVE_patch_test_case
Description: Binary data
--
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] errcontext support in PL/Perl
>From the patch review group this evening, courtesy of Webb Sprague and Brent Dombrowski. I'm replying on their behalf so that this response is in the correct thread. Looks like Peter also reviewed, but I'm forwarding this on anyway. (Note: Problem running regressions because make check doesn't descend automatically into the plperl -- we built with --with-perl successfully, but it doesn't change the behavior of make check. However, the tests do work with patch.) Per the wiki guidelines: == Submission review == * Is the patch in the standard form? Yes, * Does it apply cleanly to the current CVS HEAD? Yes * Does it include reasonable tests, docs, etc? Inline comments suffice. == Usability review == Read what the patch is supposed to do, and consider: * Does the patch actually implement that? Yes, built in to the expected test output. * Do we want that? Yes, based on the patch to Python that does similar stuff. * Do we already have it? No * Does it follow SQL spec, or the community-agreed behavior? There was extensive discussion on the list about the desirability of the context messages, and the community seems to agree in the utility * Are there dangers? No. (??) * Have all the bases been covered? We guess... == Feature test == Apply the patch, compile it and test: * Does the feature work as advertised? Make check passes, and expected output is provided (problem with automatically checking all) * Are there corner cases the author has failed to consider? Can't think of any -- popping off an empty stack or such worries me, but I couldn't determine if there was a risk of this in the code. == Performance review == * Does the patch slow down simple tests? No. * If it claims to improve performance, does it? NA * Does it slow down other things? No (?) == Coding review == Read the changes to the code in detail and consider: * Does it follow the project [http://developer.postgresql.org/pgdocs/postgres/source.html coding guidelines]? Yes * Are there portability issues? None that we can see * Will it work on Windows/BSD etc? No issues we can see * Are the comments sufficient and accurate? Yes * Does it do what it says, correctly? Yes * Does it produce compiler warnings? No * Can you make it crash? No == Architecture review == Consider the changes to the code in the context of the project as a whole: * Is everything done in a way that fits together coherently with other features/modules? Yes * Are there interdependencies than can cause problems? No, it is a simple set of changes all within plperl -- 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] community decision-making & 8.5
On Thu, Sep 3, 2009 at 11:27 AM, Tom Lane wrote: > Josh Berkus writes: >> Selena, Robert, Brendan, Kevin, >> One of the ideas behind the Alpha releases was to give someone other >> than the core team some practice doing releases. > > Uh, what's the point of that? The existing core team has that process > perfectly well in hand. What I thought this discussion was about was > putting more effort into long-range project planning/management. Ok! I was volunteering for work, not suggesting a process was broken. There's plenty to do around commitfest, so I'll stick to taking tasks there! -selena -- http://chesnok.com/daily - me http://endpoint.com - work -- 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 11:02 AM, Webb Sprague wrote: >> The CommitFest is scheduled to start 9/15, so doing this on 9/8 might >> be a bit too soon. I wouldn't object to doing it a few days before >> the start of the CommitFest to flush out any patches with obvious >> problems, but I think a week ahead of time is too much. > > Yeah, I meant Tues 9/15. > >> Also, I don't think anything is going to committed as a result of this >> - the goal is to post reviewers to pgsql-hackers. > > Sounds good. +1 -- http://chesnok.com/daily - me http://endpoint.com - work -- 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] community decision-making & 8.5
On Thu, Sep 3, 2009 at 10:21 AM, Josh Berkus wrote: > Selena, Robert, Brendan, Kevin, > > One of the ideas behind the Alpha releases was to give someone other > than the core team some practice doing releases. > > So I think it would make sense for you guys to do Alpha2. Agreed, Peter? I'm up for it! :) Like Robert as expressed on other management roles, I am not interested in doing it forever. I am certainly up for being part of a rotating team, and documenting/automating things as much as possible. -selena -- http://chesnok.com/daily - me http://endpoint.com - work -- 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] community decision-making & 8.5
On Thu, Sep 3, 2009 at 9:00 AM, Robert Haas wrote: > Yeah, I'm game, though I'm hoping not to become the guy who spends all > his time doing release planning, because I like writing code, too. > Hopefully Selena won't mind my mentioning that she sent me a private > email expressing some interest in this area, too. Not at all! My schedule is largely open this fall and winter, and I have a patch or two that I aught to finish soonish as well. -selena -- http://chesnok.com/daily - me http://endpoint.com - work -- 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] community decision-making & 8.5
On Wed, Sep 2, 2009 at 4:57 AM, Heikki Linnakangas wrote: > That implies that we need a release manager. Electing one would be the > first step. That's a lot of work and responsibility, with lots of > potential for making people cross, so in practice I think as soon as > someone steps up to the plate and volunteers to do it, he's the one. > > I'm very happy with the way you ran the first commitfest. Thank you. > Want to manage the rest as well? +1 on both points. -selena -- http://chesnok.com/daily - me http://endpoint.com - work -- 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] from_collapse_limit vs. geqo_threshold
In the spirit of helping wrap-up 8.4 todo items... Robert Haas wrote: On Mon, May 25, 2009 at 6:15 PM, Tom Lane wrote: Now I'm still not exactly happy with GEQO, but it's surely a lot better than it was in the fall of 2000. So on the whole it does seem that the current relationships between from_collapse_limit, join_collapse_limit, and geqo_threshold are based on obsolete information and should be revisited. I don't have any data at hand to suggest specific new default values, though. For 8.4, I'd be happy to just improve the documentation. I think this sentence could just be deleted from the section on from_collapse_limit: It is usually wise to keep this less than. We could put some other explanation in place of that sentence, but I'm not exactly sure what that explanation would say. I guess the point is that setting from_collapse_limit< geqo_threshold may delay GEQO planning considerably in the face of complex subqueries, because pulling up subqueries increases the size of the FROM list (I think). That could be good if you want your query plans to be more deterministic, but there's no guarantee they'll be good. Setting from_collapse_limit> geqo_threshold is basically saying that the standard planner will always have subqueries pulled up, so from_collapse_limit should be based on what the pain point will be for GEQO. My vote would be to provide some information. Suggested revision of Robert's prose: Because genetic query optimization may be triggered, increasing from_collapse_limit should be considered relative to linkend="guc-geqo-threshold">. -selena -- Selena Deckelmann End Point Corporation sel...@endpoint.com 503-282-2512 -- 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] postgresql.conf: patch to have ParseConfigFile report all parsing errors, then bail
Simon Riggs wrote: On Tue, 2009-03-10 at 07:30 -0700, Selena Deckelmann wrote: A thing that could be added, however, is reporting of all invalid (as opposed to valid, but requires a restart to apply) parameters before exiting. This change requires refactoring ProcessConfigFile() more significantly, as the parsing and validity checks are done separately, and are exited with gotos. :) I haven't tried to change this yet, but was planning to. Can't we just do a reload, but with doit = false? That would also be cool. Like an 'apachectl configtest'. There are five places where a 'goto' is used in guc-file.l needs to be changed to make this work (in addition to adding an option to pg_ctl). It should be pretty straightforward, and I'll have a look at it tonight. -selena -- Selena Deckelmann End Point Corporation -- 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] postgresql.conf: patch to have ParseConfigFile report all parsing errors, then bail
Hi! Simon Riggs wrote: On Sun, 2009-03-08 at 16:27 -0700, Selena Deckelmann wrote: ParseConfigFile currently exits on the first parsing error. Changed guc_file.l to report all parsing errors before exiting: * Moved parse_error: block inside while() loop * Removed cleanup_exit: and associated 'goto' * Added ereport if ParseConfigFile() returns false * changed OK to ok ;) * Added comment - TODO: Report bogus variables in addition to parsing errors before bailing out These are very good changes, good news. Thanks :) Is it possible to check for parameters that have been changed, yet will not be applied at reload? This was already implemented! :) For example: LOG: attempted change of parameter "shared_buffers" ignored DETAIL: This parameter cannot be changed after server start. LOG: attempted change of parameter "max_prepared_transactions" ignored DETAIL: This parameter cannot be changed after server start. A thing that could be added, however, is reporting of all invalid (as opposed to valid, but requires a restart to apply) parameters before exiting. This change requires refactoring ProcessConfigFile() more significantly, as the parsing and validity checks are done separately, and are exited with gotos. :) I haven't tried to change this yet, but was planning to. -selena -- Selena Deckelmann End Point Corporation -- 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] One less footgun: deprecating pg_dump -d
Tom Lane wrote: Greg Sabino Mullane writes: The solution I came up with is to use a new letter, -I, and to deprecate -d by having it throw an exception when used. "Deprecate" does not mean "break". This '-d' thing is more than just a matter of reading the documentation. Our other command line utilities lead a person to assume (logically) that '-d' means something completely apart from what it actually does. I've made this mistake, so have most other sysadmins I know. While this change may break existing scripts, the result is that future users of Postgres will have a much less painful experience if they accidentally try to use that option. -selena -- Selena Deckelmann End Point Corporation sel...@endpoint.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] postgresql.conf: patch to have ParseConfigFile report all parsing errors, then bail
ParseConfigFile currently exits on the first parsing error. Changed
guc_file.l to report all parsing errors before exiting:
* Moved parse_error: block inside while() loop
* Removed cleanup_exit: and associated 'goto'
* Added ereport if ParseConfigFile() returns false
* changed OK to ok ;)
* Added comment - TODO: Report bogus variables in addition to parsing
errors before bailing out
-selena
--
Selena Deckelmann
End Point Corporation
sel...@endpoint.com
503-282-2512
*** a/src/backend/utils/misc/guc-file.l
--- b/src/backend/utils/misc/guc-file.l
***
*** 143,149 ProcessConfigFile(GucContext context)
--- 143,155
if (!ParseConfigFile(ConfigFileName, NULL,
0, context, elevel,
&head, &tail))
+ {
+ ereport(elevel,
+ (errcode(ERRCODE_CONFIG_FILE_ERROR),
+errmsg("Did not reload \"%s\" due to earlier
parsing error(s)", ConfigFileName)));
+ /* TODO: Report bogus variables in addition to parsing errors
before bailing out */
goto cleanup_list;
+ }
/*
* We need the proposed new value of custom_variable_classes to check
***
*** 361,367 ParseConfigFile(const char *config_file, const char
*calling_file,
struct name_value_pair **head_p,
struct name_value_pair **tail_p)
{
! boolOK = true;
charabs_path[MAXPGPATH];
FILE *fp;
YY_BUFFER_STATE lex_buffer;
--- 367,373
struct name_value_pair **head_p,
struct name_value_pair **tail_p)
{
! boolok = true;
charabs_path[MAXPGPATH];
FILE *fp;
YY_BUFFER_STATE lex_buffer;
***
*** 461,472 ParseConfigFile(const char *config_file, const char
*calling_file,
if (!ParseConfigFile(opt_value, config_file,
depth + 1,
context, elevel,
head_p,
tail_p))
! {
! pfree(opt_name);
! pfree(opt_value);
! OK = false;
! goto cleanup_exit;
! }
yy_switch_to_buffer(lex_buffer);
ConfigFileLineno = save_ConfigFileLineno;
pfree(opt_name);
--- 467,474
if (!ParseConfigFile(opt_value, config_file,
depth + 1,
context, elevel,
head_p,
tail_p))
! ok = false;
!
yy_switch_to_buffer(lex_buffer);
ConfigFileLineno = save_ConfigFileLineno;
pfree(opt_name);
***
*** 525,552 ParseConfigFile(const char *config_file, const char
*calling_file,
/* break out of loop if read EOF, else loop for next line */
if (token == 0)
break;
- }
! /* successful completion of parsing */
! goto cleanup_exit;
! parse_error:
! if (token == GUC_EOL || token == 0)
! ereport(elevel,
! (errcode(ERRCODE_SYNTAX_ERROR),
!errmsg("syntax error in file \"%s\" line %u,
near end of line",
! config_file, ConfigFileLineno -
1)));
! else
! ereport(elevel,
! (errcode(ERRCODE_SYNTAX_ERROR),
!errmsg("syntax error in file \"%s\" line %u,
near token \"%s\"",
! config_file, ConfigFileLineno,
yytext)));
! OK = false;
! cleanup_exit:
yy_delete_buffer(lex_buffer);
FreeFile(fp);
! return OK;
}
--- 527,555
/* break out of loop if read EOF, else loop for next line */
if (token == 0)
break;
! /* skip over parse_error if we made it this far without error */
! continue;
! parse_error:
! if (token == GUC_EOL || token == 0)
! ereport(elevel,
! (errcode(ERRCODE_SYNTAX_ERROR),
!errmsg("syntax error in file
\"%s\" line %u, near end of li
Re: [HACKERS] pg_hba.conf - patch to report all parsing errors, and then bail
Magnus Hagander wrote: Applied. //Magnus Thanks. And thanks, Tom, for pointing out my multiple attempts to free. -selena -- Selena Deckelmann End Point Corporation sel...@endpoint.com 503-282-2512 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] pg_hba.conf - patch to report all parsing errors, and then bail
Currently, load_hba() bails on the first parsing error. It would be
better for the typo-prone sysadmin if it reported ALL errors, and THEN
bailed out.
This patch implements that behavior. Tested against 8.4 HEAD this morning.
Idea is to do a similar thing for postgresql.conf. That is a little more
complicated and will be a separate patch.
-selena
--
Selena Deckelmann
End Point Corporation
sel...@endpoint.com
503-282-2512
diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
index 6923d06..c6a7ba7 100644
--- a/src/backend/libpq/hba.c
+++ b/src/backend/libpq/hba.c
@@ -1304,6 +1304,7 @@ load_hba(void)
List *hba_line_nums = NIL;
ListCell *line, *line_num;
List *new_parsed_lines = NIL;
+ bool OK = true;
file = AllocateFile(HbaFileName, "r");
if (file == NULL)
@@ -1332,17 +1333,22 @@ load_hba(void)
if (!parse_hba_line(lfirst(line), lfirst_int(line_num),
newline))
{
- /* Parse error in the file, so bail out */
+ /* Parse error in the file, so indicate there's a
problem */
free_hba_record(newline);
pfree(newline);
clean_hba_list(new_parsed_lines);
/* Error has already been reported in the parsing
function */
- return false;
+ OK = false;
+ continue;
}
new_parsed_lines = lappend(new_parsed_lines, newline);
}
+ if (!OK)
+ /* Parsing failed, so bail out */
+ return false;
+
/* Loaded new file successfully, replace the one we use */
clean_hba_list(parsed_hba_lines);
parsed_hba_lines = new_parsed_lines;
--
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] Make SIGHUP less painful if pg_hba.conf is not readable
Tom Lane wrote: > Selena Deckelmann writes: >> From the comment in hba.c, it appears that the desired behavior is to >> have the system ignore the failure, > > I'm not sure how you could possibly read that comment that way. Right. Sorry, poor choice of words. I meant "don't die on reload", essentially. > It might be sane to distinguish initial load from reload, but I think > the behavior is correct as-is for initial load. Agreed. > Also, if we are going to do something like this, we should make sure > it's consistent across all the config files. Ok. I can do that. I'll check with some other people before I send another patch, and I'll go through the rest of the config file loads tomorrow. -selena -- Selena Deckelmann End Point Corporation sel...@endpoint.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] Make SIGHUP less painful if pg_hba.conf is not readable
This is my first patch. I hope it's not stupid.
We ran into a little issue today where permission/ownership on
pg_hba.conf was accidentally changed to something that the postgres user
could not read. When a SIGHUP was issued, the postmaster quit. That was
kind of a bummer.
>From the comment in hba.c, it appears that the desired behavior is to
have the system ignore the failure, and continue using what's already
loaded into memory. And, turns out, that's what I would like Postgres
to do as well.
So, this patch changes the error issued from load_hba() from FATAL to
WARNING if the file is not found, and returns.
Startup behavior (FATAL if pg_hba.conf can't be found) is not changed.
Tested against 8.4devel HEAD today.
Patch attached.
--
Selena Deckelmann
End Point Corporation
sel...@endpoint.com
diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c
index a134b45..931ca86 100644
--- a/src/backend/libpq/hba.c
+++ b/src/backend/libpq/hba.c
@@ -1307,11 +1307,14 @@ load_hba(void)
file = AllocateFile(HbaFileName, "r");
/* Failure is fatal since with no HBA entries we can do nothing... */
- if (file == NULL)
- ereport(FATAL,
+ if (file == NULL)
+ {
+ ereport(WARNING,
(errcode_for_file_access(),
errmsg("could not open configuration file
\"%s\": %m",
HbaFileName)));
+ return false;
+ }
tokenize_file(HbaFileName, file, &hba_lines, &hba_line_nums);
FreeFile(file);
--
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] [pgsql-advocacy] Please submit for OSCON!
On Jan 3, 2008 2:53 PM, Josh Berkus <[EMAIL PROTECTED]> wrote: > We may or may not be having a PostgreSQL Day before OSCON (Josh, Selena?) > but we'll keep people posted. But submit a talk today! I'd love to have another PostgreSQL Day before OSCON. Let's just do it. We're working on East right now, but I'll see if PDXPUG can step up with some organization support. -- Selena Deckelmann PDXPUG - Portland PostgreSQL Users Group http://pugs.postgresql.org/pdx http://www.chesnok.com/daily ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [DOCS] [HACKERS] Uniform policy for author credits in contrib module documentation?
On Dec 7, 2007 9:03 AM, Andrew Dunstan <[EMAIL PROTECTED]> wrote: > > > Joshua D. Drake wrote: > > Tom Lane wrote: > >> Josh Berkus <[EMAIL PROTECTED]> writes: > >>> Historically, the only way to troubleshoot some of the contrib > >>> modules was to e-mail the author. If people think that we've > >>> reached a standard that everything in /contrib is now > >>> well-documented and supported by the general community, the I > >>> suppose we don't need contact information. I'm not so sure myself. > >> > >> I do not think that we should encourage people to mail the authors first > >> rather than pgsql-bugs. For one thing, a lot of those addresses are > >> dead, and some of the ones that aren't don't respond especially fast. > >> > >> If the community-at-large can't handle a bug, we certainly have enough > >> institutional memory to try to contact the original author, even if that > >> address isn't in the SGML docs. > >> > > > > Perhaps the at a minimum the email goes in the commit? > > > > I don't see any reason, unless we're going to start doing that for all > contributions. 'contrib' is a serious misnomer anyway, and there's no > reason to think in general that the original author is specially > responsible for any of it. I think Tom's point is entirely valid. I think it is totally appropriate to replace the email address contact information with a link to pgsql-bugs. But there are reasons other than bugfixing to contact the original author of a patch or contrib packages. Some of those could include: * collaboration on a professional, hobby or academic research level * journalism/books written about PostgreSQL * academic or historical research into the development of PostgreSQL * job prospects * socializing For those reasons, I think it would be a huge loss to the community to remove the credit sections or to prevent their inclusion in future documentation. Maintaining them leaves a breadcrumb trail that otherwise would be lost in mailing list threads and commit logs that are very difficult for a person without specialized knowledge to navigate. Why make contacting people hard? Some of the contrib features are likely targets for future research and development (for example: tsearch, HOT, pl/lolcode - not contrib, but awesome!) and in that context, the specific people involved are important. Contrib documentation will get folded into the main docs eventually (and at that point, the credits are removed). But the record of that evolution is easily accessed, without any special knowledge of a revision control system, or mailing list culture. And I realize that the logical extension of what I am saying is a research and documentation project about the people who all have contributed to the development of PostgreSQL. -selena -- Selena Deckelmann PDXPUG - Portland PostgreSQL Users Group http://pugs.postgresql.org/pdx http://www.chesnok.com/daily ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [DOCS] Uniform policy for author credits in contrib module documentation?
On Dec 5, 2007 8:58 PM, Tom Lane <[EMAIL PROTECTED]> wrote: > If we do want to keep credits in the SGML pages, how extensive should > they be? ... > I don't have a strong opinion one way or the other, except that I think > we should have a uniform policy for all the contrib modules. One of the things that I used to do with the old HOWTO documentation from the Linux Documentation Project was jump directly to the Acknowledgement or Credit sections and read who the author had decided to thank, and then search for more information about those people and what they had done. While it might be a pain to maintain that information, it does humanize and provide context for a document. Also, the tradition of thanking people (or higher powers) and taking a few moments to reflect on who might have helped one accomplish something is a good one. Maybe I'm just being nostalgic, but I like that the content of credit sections is not uniform. Rather than remove credits, we could apply a regex to obfuscate the email addresses, and offer a mention to authors in the more general contributors area when packages are added. -selena -- Selena Deckelmann PDXPUG - Portland PostgreSQL Users Group http://pugs.postgresql.org/pdx http://www.chesnok.com/daily ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
