Re: [HACKERS] alpha4 timing
On ons, 2010-02-17 at 15:59 -0800, Josh Berkus wrote: > On 2/17/10 3:05 PM, Peter Eisentraut wrote: > > On ons, 2010-02-17 at 14:58 -0800, Josh Berkus wrote: > >> On 2/17/10 2:08 PM, Peter Eisentraut wrote: > >>> FYI: 9.0alpha4 will be wrapped tomorrow (Thursday) and released > >>> Friday'ish. > >> Can you get me release notes RSN so that I can edit them? > > > > I don't have any release notes yet. Feel free to pitch in ... > > Gah, I won't have any serious writing time until tommorrow evening (US > time). Committed. Edit away. -- 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] alpha4 timing
Peter Eisentraut writes: > On ons, 2010-02-17 at 14:58 -0800, Josh Berkus wrote: >> On 2/17/10 2:08 PM, Peter Eisentraut wrote: >>> FYI: 9.0alpha4 will be wrapped tomorrow (Thursday) and released >>> Friday'ish. >> >> Can you get me release notes RSN so that I can edit them? > I don't have any release notes yet. Feel free to pitch in ... FWIW, I dug through the CVS logs and picked out all the commit messages that seem worth including since alpha3. Too tired to do more than that ... regards, tom lane 2010-02-16 17:34 tgl * Replace the pg_listener-based LISTEN/NOTIFY mechanism with an in-memory queue. In addition, add support for a "payload" string to be passed along with each notify event. This implementation should be significantly more efficient than the old one, and is also more compatible with Hot Standby usage. There is not yet any facility for HS slaves to receive notifications generated on the master, although such a thing is possible in future. Joachim Wieland, reviewed by Jeff Davis; also hacked on by me. 2010-02-16 17:19 adunstan * Add query text to auto_explain output. Still to be done: fix docs and fix regression failures under auto_explain. 2010-02-16 16:39 adunstan * Clean up package namespace use and use of Safe in plperl. Prevent use of another buggy version of Safe.pm. Only register the exit handler if we have successfully created an interpreter. Change log level of perl warnings from NOTICE to WARNING. The infrastructure is there if in future we decide to allow DBAs to specify extra modules that will be allowed in trusted code. However, for now the relevant variables are declared as lexicals rather than as package variables, so that they are not (or should not be) accessible. Mostly code from Tim Bunce, reviewed by Alex Hunsaker, with some tweaks by me. 2010-02-16 16:18 momjian * Honor to_char() "FM" specification in YYY, YY, and Y; it was already honored by . Also document Oracle "toggle" FM behavior. Per report from Guy Rouillier 2010-02-16 15:58 momjian * Have SELECT and CREATE TABLE AS queries return a row count. While this is invisible in psql, other interfaces, like libpq, make this value visible. Boszormenyi Zoltan 2010-02-12 14:35 adunstan * Add plperl.on_plperl_init and plperl.on_plperlu_init settings for language-specific startup. Rename recently added plperl.on_perl_init to plperl.on_init. Also, code cleanup for utf8 hack. Patch from Tim Bunce, reviewed by Alex Hunsaker. 2010-02-12 12:33 tgl * Extend the set of frame options supported for window functions. This patch allows the frame to start from CURRENT ROW (in either RANGE or ROWS mode), and it also adds support for ROWS n PRECEDING and ROWS n FOLLOWING start and end points. (RANGE value PRECEDING/FOLLOWING isn't there yet --- the grammar works, but that's all.) Hitoshi Harada, reviewed by Pavel Stehule 2010-02-11 09:29 teodor * Generic implementation of red-black binary tree. It's planned to use in several places, but for now only GIN uses it during index creation. Using self-balanced tree greatly speeds up index creation in corner cases with preordered data. 2010-02-09 16:43 tgl * Fix up rickety handling of relation-truncation interlocks. Move rd_targblock, rd_fsm_nblocks, and rd_vm_nblocks from relcache to the smgr relation entries, so that they will get reset to InvalidBlockNumber whenever an smgr-level flush happens. Because we now send smgr invalidation messages immediately (not at end of transaction) when a relation truncation occurs, this ensures that other backends will reset their values before they next access the relation. We no longer need the unreliable assumption that a VACUUM that's doing a truncation will hold its AccessExclusive lock until commit --- in fact, we can intentionally release that lock as soon as we've completed the truncation. This patch therefore reverts (most of) Alvaro's patch of 2009-11-10, as well as my marginal hacking on it yesterday. We can also get rid of assorted no-longer-needed relcache flushes, which are far more expensive than an smgr flush because they kill a lot more state. In passing this patch fixes smgr_redo's failure to perform visibility-map truncation, and cleans up some rather dubious assumptions in freespace.c and visibilitymap.c about when
Re: [HACKERS] alpha4 timing
On 2/17/10 3:05 PM, Peter Eisentraut wrote: > On ons, 2010-02-17 at 14:58 -0800, Josh Berkus wrote: >> On 2/17/10 2:08 PM, Peter Eisentraut wrote: >>> FYI: 9.0alpha4 will be wrapped tomorrow (Thursday) and released >>> Friday'ish. >> Can you get me release notes RSN so that I can edit them? > > I don't have any release notes yet. Feel free to pitch in ... Gah, I won't have any serious writing time until tommorrow evening (US time). --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] alpha4 timing
On ons, 2010-02-17 at 14:58 -0800, Josh Berkus wrote: > On 2/17/10 2:08 PM, Peter Eisentraut wrote: > > FYI: 9.0alpha4 will be wrapped tomorrow (Thursday) and released > > Friday'ish. > > Can you get me release notes RSN so that I can edit them? I don't have any release notes yet. Feel free to pitch in ... -- 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] alpha4 timing
On 2/17/10 2:08 PM, Peter Eisentraut wrote: > FYI: 9.0alpha4 will be wrapped tomorrow (Thursday) and released > Friday'ish. Can you get me release notes RSN so that I can edit them? --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] alpha4 timing
Peter Eisentraut wrote: > FYI: 9.0alpha4 will be wrapped tomorrow (Thursday) and released > Friday'ish. No much time for a translation update I guess ... -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] alpha4 timing
FYI: 9.0alpha4 will be wrapped tomorrow (Thursday) and released Friday'ish. -- 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] alpha4 timing (was: Speed up CREATE DATABASE)
Robert Haas writes: > On Mon, Feb 15, 2010 at 6:19 AM, Greg Stark wrote: >> When do we cut the alpha? If I look at it at about 10-11pm EST is that too >> late? > It looks like it's going to take Andrew until tomorrow to commit the > last perl patch, so I think we should plan to cut the alpha on > Wednesday if nothing comes up. Wednesday would be about the earliest possible point --- probably end of the week would be safer. > On a related note, should we go ahead and do the 8.5 -> 9.0 > renumbering at this point? Is someone already working on this? I was planning to do it once the other dust settles. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] alpha4 timing (was: Speed up CREATE DATABASE)
Robert Haas escribió: > On Mon, Feb 15, 2010 at 6:19 AM, Greg Stark wrote: > > When do we cut the alpha? If I look at it at about 10-11pm EST is that too > > late? > > It looks like it's going to take Andrew until tomorrow to commit the > last perl patch, so I think we should plan to cut the alpha on > Wednesday if nothing comes up. Hmm, we need a translation update! -- Alvaro Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] alpha4 timing (was: Speed up CREATE DATABASE)
On Mon, Feb 15, 2010 at 6:19 AM, Greg Stark wrote: > When do we cut the alpha? If I look at it at about 10-11pm EST is that too > late? It looks like it's going to take Andrew until tomorrow to commit the last perl patch, so I think we should plan to cut the alpha on Wednesday if nothing comes up. On a related note, should we go ahead and do the 8.5 -> 9.0 renumbering at this point? Is someone already working on this? ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
