[HACKERS] Release notes for next week's minor releases are up for review

[Tom Lane]

... at
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=42de8a0255c2509bf179205e94b9d65f9d6f3cf9

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] release notes for v10

[Bruce Momjian]

On Thu, Mar 30, 2017 at 06:23:04PM -0400, Robert Haas wrote:
> Hi,
> 
> One of the things we'll need to do to get 10beta1 out the door is have
> a set of release notes.  I spoke with Bruce Momjian today at PGCONF.US
> and he told me that he has set aside time during April to write them
> and will begin working on it once we reach feature freeze.  I think
> this is good, because last year Bruce didn't have time and we had to
> scramble to find somebody, with Tom Lane luckily stepping up to the
> plate.
> 
> Bruce, please confirm that I've got the message right.

Yes, confirmed, the release notes will be ready by the end of April.

-- 
  Bruce Momjian  http://momjian.us
  EnterpriseDB http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+  Ancient Roman grave inscription +


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] release notes for v10

[Robert Haas]

Hi,

One of the things we'll need to do to get 10beta1 out the door is have
a set of release notes.  I spoke with Bruce Momjian today at PGCONF.US
and he told me that he has set aside time during April to write them
and will begin working on it once we reach feature freeze.  I think
this is good, because last year Bruce didn't have time and we had to
scramble to find somebody, with Tom Lane luckily stepping up to the
plate.

Bruce, please confirm that I've got the message right.

Thanks,

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Release notes of 9.0~9.3 mentioning recovery_min_apply_delay incorrectly

[Michael Paquier]

Hi all,

While doing a git grep on recovery_min_apply_delay I noticed the following:
$ git grep recovery_min_apply -- *release*.sgml
src/sgml/release-9.0.sgml:  that recovery_min_apply_delay
failed to delay application
src/sgml/release-9.1.sgml:  that recovery_min_apply_delay
failed to delay application
src/sgml/release-9.2.sgml:  that recovery_min_apply_delay
failed to delay application
src/sgml/release-9.3.sgml:  that recovery_min_apply_delay
failed to delay application
src/sgml/release-9.4.sgml:  Avoid busy-waiting with short
recovery_min_apply_delay

This is obviously incorrect because recovery_min_apply_delay has been only
introduced in 9.4. The culprit is visibly the commit message of 8049839 and
others that mentioned the parameter, though the patch applied does nothing
about it. Please see attached a patch to fix that.
Regards,
-- 
Michael
diff --git a/doc/src/sgml/release-9.0.sgml b/doc/src/sgml/release-9.0.sgml
index ef8eb1c..de6550f 100644
--- a/doc/src/sgml/release-9.0.sgml
+++ b/doc/src/sgml/release-9.0.sgml
@@ -1493,12 +1493,6 @@
   Fix several cases where recovery logic improperly ignored WAL records
   for COMMIT/ABORT PREPARED (Heikki Linnakangas)
  
-
- 
-  The most notable oversight was
-  that recovery_min_apply_delay failed to delay application
-  of a two-phase commit.
- 
 
 
 
diff --git a/doc/src/sgml/release-9.1.sgml b/doc/src/sgml/release-9.1.sgml
index fde6b61..ef2e849 100644
--- a/doc/src/sgml/release-9.1.sgml
+++ b/doc/src/sgml/release-9.1.sgml
@@ -1663,12 +1663,6 @@ Branch: REL9_0_STABLE [9d6af7367] 2015-08-15 11:02:34 -0400
   Fix several cases where recovery logic improperly ignored WAL records
   for COMMIT/ABORT PREPARED (Heikki Linnakangas)
  
-
- 
-  The most notable oversight was
-  that recovery_min_apply_delay failed to delay application
-  of a two-phase commit.
- 
 
 
 
diff --git a/doc/src/sgml/release-9.2.sgml b/doc/src/sgml/release-9.2.sgml
index 4bfede5..72203fb 100644
--- a/doc/src/sgml/release-9.2.sgml
+++ b/doc/src/sgml/release-9.2.sgml
@@ -1848,12 +1848,6 @@ Branch: REL9_2_STABLE [6b700301c] 2015-02-17 16:03:00 +0100
   Fix several cases where recovery logic improperly ignored WAL records
   for COMMIT/ABORT PREPARED (Heikki Linnakangas)
  
-
- 
-  The most notable oversight was
-  that recovery_min_apply_delay failed to delay application
-  of a two-phase commit.
- 
 
 
 
diff --git a/doc/src/sgml/release-9.3.sgml b/doc/src/sgml/release-9.3.sgml
index 1ac6abe..a1a7781 100644
--- a/doc/src/sgml/release-9.3.sgml
+++ b/doc/src/sgml/release-9.3.sgml
@@ -2413,12 +2413,6 @@ Branch: REL9_0_STABLE [804983961] 2014-07-29 11:58:17 +0300
   Fix several cases where recovery logic improperly ignored WAL records
   for COMMIT/ABORT PREPARED (Heikki Linnakangas)
  
-
- 
-  The most notable oversight was
-  that recovery_min_apply_delay failed to delay application
-  of a two-phase commit.
- 
 
 
 

Re: [HACKERS] Release notes of 9.0~9.3 mentioning recovery_min_apply_delay incorrectly

[Tom Lane]

Michael Paquier  writes:
> This is obviously incorrect because recovery_min_apply_delay has been only
> introduced in 9.4. The culprit is visibly the commit message of 8049839 and
> others that mentioned the parameter, though the patch applied does nothing
> about it. Please see attached a patch to fix that.

Good catch!  That's on me I guess for not checking what the patch had done
in the back branches.

I didn't like simply deleting any description of the patch's effects, though.
Instead I made it talk about recovery_target_xid, which does exist in all
those branches.

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

[HACKERS] Release notes committed

[Tom Lane]

I've committed the release notes for today's releases, if anyone wants
to take a look.  Fortunately, there's not much to them.  Unfortunately,
I need to start the wrap process in about an hour, so there's not much
time to review either :-(

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] Release notes

[Andres Freund]

On 2015-01-27 10:09:12 -0800, Joshua D. Drake wrote:
 Where can one find the running copy of release notes for pending releases?

In the source tree on the master once it exists. It doesn't yet for the
next set of releases.

Greetings,

Andres Freund

-- 
 Andres Freund http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training  Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Release notes

[Joshua D. Drake]

Where can one find the running copy of release notes for pending releases?
--
Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, @cmdpromptinc
If we send our children to Caesar for their education, we should
 not be surprised when they come back as Romans.


--
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] Release notes

[Tom Lane]

Andres Freund and...@2ndquadrant.com writes:
 On 2015-01-27 10:09:12 -0800, Joshua D. Drake wrote:
 Where can one find the running copy of release notes for pending releases?

 In the source tree on the master once it exists. It doesn't yet for the
 next set of releases.

The closest thing to a running copy is the git commit log.  Somebody
(usually Bruce or I) writes release notes from that shortly before a
release is made.

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] Release notes

[Joshua D. Drake]

On 01/27/2015 10:17 AM, Tom Lane wrote:

Andres Freund and...@2ndquadrant.com writes:

On 2015-01-27 10:09:12 -0800, Joshua D. Drake wrote:

Where can one find the running copy of release notes for pending releases?



In the source tree on the master once it exists. It doesn't yet for the
next set of releases.


The closest thing to a running copy is the git commit log.  Somebody
(usually Bruce or I) writes release notes from that shortly before a
release is made.


Thanks for the info.

JD



--
Command Prompt, Inc. - http://www.commandprompt.com/  503-667-4564
PostgreSQL Support, Training, Professional Services and Development
High Availability, Oracle Conversion, @cmdpromptinc
If we send our children to Caesar for their education, we should
 not be surprised when they come back as Romans.


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Release notes git attribution

[Marti Raudsepp]

Hi,

The 9.2.3 release notes say:
* Fix pg_upgrade's -O/-o options (Bruce Momjian)

You got it the wrong way around, he was the one who introduced the bug! ;)

I originally found, debugged and provided the fix:
http://www.postgresql.org/message-id/cabrt9rby1urtmy-dfldgbpcp+zqu36m_+bld4wfwugohg-m...@mail.gmail.com

No big deal, it was just one space, but I wanted to voice my
disagreement with how Postgres committers don't retain original patch
authorship information.

Regards,
Marti


-- 
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] Release notes git attribution

[Simon Riggs]

On 8 February 2013 09:43, Marti Raudsepp ma...@juffo.org wrote:

 No big deal, it was just one space, but I wanted to voice my
 disagreement with how Postgres committers don't retain original patch
 authorship information.

I agree its very important to get that right.

It's important for the PostgreSQL project to encourage further
contribution by acknowledging and celebrating contributions, as well
as allowing external observers to see that work was done successfully
by particular people to confirm further sponsorship/time allocation
etc. That practice has long been followed and encouraged by the core
team and committers.

Some mistakes are made from time to time but there is a willingness to
make corrections to that.

I'll look into this.

-- 
 Simon Riggs   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training  Services


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Release notes git attribution

[Tom Lane]

Marti Raudsepp ma...@juffo.org writes:
 The 9.2.3 release notes say:
 * Fix pg_upgrade's -O/-o options (Bruce Momjian)

 You got it the wrong way around, he was the one who introduced the bug! ;)

Sorry about that.  The release notes are made based on commit-log
entries.  In this case we had

Author: Bruce Momjian br...@momjian.us
Branch: master [acdb8c225] 2012-12-10 23:03:25 -0500
Branch: REL9_2_STABLE [35fb1434b] 2012-12-10 23:03:28 -0500

Fix pg_upgrade -O/-o options

Fix previous commit that added synchronous_commit=off, but broke -O/-o
due to missing space in argument passing.

Backpatch to 9.2.

so it was Bruce's error not to credit you in the commit message.
I know that he knows better --- it is project policy to properly credit
patch authors.  But mistakes do happen, of course.  Again, my apologies
on behalf of the project.

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

PL/Perl function naming (was: [HACKERS] release notes)

[Tim Bunce]

[Sorry for the delay. I'd stopped checking the pgsql mailing lists.
Thanks to David Wheeler and Josh Berkus for the heads-up.]

On Sun, May 30, 2010 at 06:58:32PM -0400, Andrew Dunstan wrote:
 
 Tim Bunce wrote:
 On Mon, May 17, 2010 at 11:34:37AM -0400, Tom Lane wrote:
 Andrew Dunstan and...@dunslane.net writes:
 Why do the release notes say this, under plperl:
 * PL/Perl subroutines are now given names (Tim Bunce)
   This is for the use of profiling and code coverage tools. DIDN'T
   THEY HAVE NAMES BEFORE?
If whoever put this in the release notes had bothered
 to ask I am sure we would have been happy to explain.
 You don't need to complain, just fix it.  The point of the comment is
 that more explanation is needed.
 
 I think you can just delete it. It's too esoteric to be worth noting.
 
 Tim.
 
 p.s. It also turned to be insufficiently useful for NYTProf since it
 doesn't also update some internals to record the 'filename' and line
 number range of the sub. So PostgreSQL::PLPerl::NYTProf works around
 that by wrapping mkfuncsrc() to edit the generated perl code to include
 a subname in the usual sub $name { ... } style. I may offer a patch
 for 9.1 to to make it work that way.

 I put this aside to think about it.
 
 If the feature is not any use should we rip it out? We pretty much
 included it because you said it was what you needed for the
 profiler.

Yes, it can go.

*** a/src/pl/plperl/plperl.c
--- b/src/pl/plperl/plperl.c
*** plperl_create_sub(plperl_proc_desc *prod
*** 1319,1328 
(errmsg(didn't get a CODE ref from compiling 
%s,
prodesc-proname)));

-   /* give the subroutine a proper name in the main:: symbol table */
-   CvGV(SvRV(subref)) = (GV *) newSV(0);
-   gv_init(CvGV(SvRV(subref)), PL_defstash, subname, strlen(subname), 
TRUE);
-   
prodesc-reference = subref;

return;

 I'm seriously nervous about adding function names - making functions
 directly callable like that could be a major footgun recipe, since
 now we are free to hide some stuff in the calling mechanism, and can
 (and have in the past) changed that to suit our needs, e.g. when we
 added trigger support via a hidden function argument. That has been
 safe precisely because nobody has had a handle on the subroutine
 which would enable it to be called directly from perl code. There
 have been suggestions in the past of using this for other features,
 so we should not assume that the calling mechanism is fixed in stone.

Agreed. It is a very hard to use footgun though because the oid is
included in the name. It's certainly not something anyone would shoot
themselves with by accident.

[Speaking of calling conventions: I never did get time for some decent
performance optimization. I'd like to get rid of the explicit extra
trigger data argument and corresponding local $_TD=shift; prologue.
That could be done much faster in C.]

 Perhaps we could decorate the subs with attributes, or is that not
 doable for anonymous subs?

Perhaps. I'll look into it when I get around to working on the PL/Perl
NYTProf again. For the profiler it would be enough to only enable the
naming when the appropriate perl debugging flag bits are set, so it
wouldn't happen normally.

Tim.

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] release notes

[Robert Haas]

On Sun, May 30, 2010 at 6:58 PM, Andrew Dunstan and...@dunslane.net wrote:
 Tim Bunce wrote:
 p.s. It also turned to be insufficiently useful for NYTProf since it
 doesn't also update some internals to record the 'filename' and line
 number range of the sub. So PostgreSQL::PLPerl::NYTProf works around
 that by wrapping mkfuncsrc() to edit the generated perl code to include
 a subname in the usual sub $name { ... } style. I may offer a patch
 for 9.1 to to make it work that way.

 I put this aside to think about it.

 If the feature is not any use should we rip it out? We pretty much
 included it because you said it was what you needed for the profiler.

 I'm seriously nervous about adding function names - making functions
 directly callable like that could be a major footgun recipe, since now we
 are free to hide some stuff in the calling mechanism, and can (and have in
 the past) changed that to suit our needs, e.g. when we added trigger support
 via a hidden function argument. That has been safe precisely because nobody
 has had a handle on the subroutine which would enable it to be called
 directly from perl code. There have been suggestions in the past of using
 this for other features, so we should not assume that the calling mechanism
 is fixed in stone.

 Perhaps we could decorate the subs with attributes, or is that not doable
 for anonymous subs?

This is still on our open items list - should we do anything about it?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] release notes

[Andrew Dunstan]

Tim Bunce wrote:

On Mon, May 17, 2010 at 11:34:37AM -0400, Tom Lane wrote:
  

Andrew Dunstan and...@dunslane.net writes:


Why do the release notes say this, under plperl:
* PL/Perl subroutines are now given names (Tim Bunce)
  This is for the use of profiling and code coverage tools. DIDN'T
  THEY HAVE NAMES BEFORE?
  
If whoever put this in the release notes had bothered to ask I am sure 
we would have been happy to explain.
  

You don't need to complain, just fix it.  The point of the comment is
that more explanation is needed.



I think you can just delete it. It's too esoteric to be worth noting.

Tim.

p.s. It also turned to be insufficiently useful for NYTProf since it
doesn't also update some internals to record the 'filename' and line
number range of the sub. So PostgreSQL::PLPerl::NYTProf works around
that by wrapping mkfuncsrc() to edit the generated perl code to include
a subname in the usual sub $name { ... } style. I may offer a patch
for 9.1 to to make it work that way.

  

I put this aside to think about it.

If the feature is not any use should we rip it out? We pretty much 
included it because you said it was what you needed for the profiler.


I'm seriously nervous about adding function names - making functions 
directly callable like that could be a major footgun recipe, since now 
we are free to hide some stuff in the calling mechanism, and can (and 
have in the past) changed that to suit our needs, e.g. when we added 
trigger support via a hidden function argument. That has been safe 
precisely because nobody has had a handle on the subroutine which would 
enable it to be called directly from perl code. There have been 
suggestions in the past of using this for other features, so we should 
not assume that the calling mechanism is fixed in stone.


Perhaps we could decorate the subs with attributes, or is that not 
doable for anonymous subs?


cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] release notes

[Bruce Momjian]

Andrew Dunstan wrote:
 
 
 Tom Lane wrote:
  Andrew Dunstan and...@dunslane.net writes:

  OK ... I guess I was bothered because this has been referred to in a 
  public press release about the Beta. The PLPerl security stuff is 
  missing too, so I'll fix that also.
  
 
  The security stuff isn't relevant to the 9.0 notes, since it's already
  been fixed in a previous release.  In general we don't document bug
  fixes in a major release if they already appeared in previous
  back-patches; the major release notes are quite verbose enough without
  such duplication.  (In effect, the idea is that major release notes
  should represent the delta from the previous major release *as it stood
  at the time of the new major release*.)

 
 
 OK, then I will just remove the now redundant item regarding Safe.pm.

Yes, please make whatever updates to the release notes you feel are
appropriate.

-- 
  Bruce Momjian  br...@momjian.ushttp://momjian.us
  EnterpriseDB http://enterprisedb.com

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] release notes

[Tim Bunce]

On Mon, May 17, 2010 at 11:34:37AM -0400, Tom Lane wrote:
 Andrew Dunstan and...@dunslane.net writes:
  Why do the release notes say this, under plperl:
  * PL/Perl subroutines are now given names (Tim Bunce)
This is for the use of profiling and code coverage tools. DIDN'T
THEY HAVE NAMES BEFORE?
 
  If whoever put this in the release notes had bothered to ask I am sure 
  we would have been happy to explain.
 
 You don't need to complain, just fix it.  The point of the comment is
 that more explanation is needed.

I think you can just delete it. It's too esoteric to be worth noting.

Tim.

p.s. It also turned to be insufficiently useful for NYTProf since it
doesn't also update some internals to record the 'filename' and line
number range of the sub. So PostgreSQL::PLPerl::NYTProf works around
that by wrapping mkfuncsrc() to edit the generated perl code to include
a subname in the usual sub $name { ... } style. I may offer a patch
for 9.1 to to make it work that way.

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] release notes

[Andrew Dunstan]

Why do the release notes say this, under plperl:

   * PL/Perl subroutines are now given names (Tim Bunce)
 This is for the use of profiling and code coverage tools. DIDN'T
 THEY HAVE NAMES BEFORE?


No they didn't, from perl's perspective, which is what this is about. 
They had names from Postgres' POV, but those names were and are 
invisible to perl. PL/Perl functions are (references to) anonymous 
subroutines. If you say in perl:


   my $foo = sub { $bar = 1; };

the subroutine has no name. The only thing that has a name is the 
reference to it, which is quite a different thing. PL/Perl functions are 
created using this sort of mechanism. The change that has been made is 
to decorate them with names that can be used by profilers etc., although 
the names can't be used to call them directly, IIRC.


If whoever put this in the release notes had bothered to ask I am sure 
we would have been happy to explain.


cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] release notes

[Tom Lane]

Andrew Dunstan and...@dunslane.net writes:
 Why do the release notes say this, under plperl:
 * PL/Perl subroutines are now given names (Tim Bunce)
   This is for the use of profiling and code coverage tools. DIDN'T
   THEY HAVE NAMES BEFORE?

 If whoever put this in the release notes had bothered to ask I am sure 
 we would have been happy to explain.

You don't need to complain, just fix it.  The point of the comment is
that more explanation is needed.

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] release notes

[Andrew Dunstan]

Tom Lane wrote:

Andrew Dunstan and...@dunslane.net writes:
  

Why do the release notes say this, under plperl:
* PL/Perl subroutines are now given names (Tim Bunce)
  This is for the use of profiling and code coverage tools. DIDN'T
  THEY HAVE NAMES BEFORE?



  
If whoever put this in the release notes had bothered to ask I am sure 
we would have been happy to explain.



You don't need to complain, just fix it.  The point of the comment is
that more explanation is needed.


  


OK ... I guess I was bothered because this has been referred to in a 
public press release about the Beta. The PLPerl security stuff is 
missing too, so I'll fix that also.


cheers

andrew

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] release notes

[Tom Lane]

Andrew Dunstan and...@dunslane.net writes:
 OK ... I guess I was bothered because this has been referred to in a 
 public press release about the Beta. The PLPerl security stuff is 
 missing too, so I'll fix that also.

The security stuff isn't relevant to the 9.0 notes, since it's already
been fixed in a previous release.  In general we don't document bug
fixes in a major release if they already appeared in previous
back-patches; the major release notes are quite verbose enough without
such duplication.  (In effect, the idea is that major release notes
should represent the delta from the previous major release *as it stood
at the time of the new major release*.)

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] release notes

[Andrew Dunstan]

Tom Lane wrote:

Andrew Dunstan and...@dunslane.net writes:
  
OK ... I guess I was bothered because this has been referred to in a 
public press release about the Beta. The PLPerl security stuff is 
missing too, so I'll fix that also.



The security stuff isn't relevant to the 9.0 notes, since it's already
been fixed in a previous release.  In general we don't document bug
fixes in a major release if they already appeared in previous
back-patches; the major release notes are quite verbose enough without
such duplication.  (In effect, the idea is that major release notes
should represent the delta from the previous major release *as it stood
at the time of the new major release*.)
  



OK, then I will just remove the now redundant item regarding Safe.pm.

cheers

andrew


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Release Notes 9.0: substring() changes?

[Erik Rijkers]

In the 9.0devel release notes

  http://developer.postgresql.org/pgdocs/postgres/release-9-0.html

under

  E.1.2.3. String Handling

three changes are mentioned, and for the first two changes it is said that 
substring() is affected:

8
1
  Properly treat ^ and $ as literals in SIMILAR TO patterns, to match the SQL 
standard (Tom Lane)
Previously these were treated using regular expression syntax. This change 
breaks backward
compatibility. This also affects substring()'s interpretation of regular 
expressions.

2
  Process parentheses as literals in SIMILAR TO expressions; also make 
character class handling
more standards-compliant (Tom Lane)
  This also affects substring()'s handling of regular expressions.

3
   Do not allow substring()  to have a negative third length, per the SQL 
standard (Tom Lane)
8

In 9.0devel cvs, I can find  affirm the SIMILAR TO changes, but I cannot find 
any changes to
substring() (other than the one under point 3.)


# select current_setting('server_version_num');
 current_setting
-
 9

# select substring('The quick brown fox', E'^The (quick) brown');
 substring
---
 quick
(1 row)

This shows that both  ^ and parentheses are regex-interpreted, and not 
literally as the
release-note text would have one believe.

Perhaps those mentions of substring-change under point 1 and 2 can be removed?


thanks,

Erik Rijkers



-- 
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] Release Notes 9.0: substring() changes?

[Tom Lane]

Erik Rijkers e...@xs4all.nl writes:
 In 9.0devel cvs, I can find  affirm the SIMILAR TO changes, but I cannot 
 find any changes to
 substring() (other than the one under point 3.)

What's affected is the three-parameter form of SUBSTRING().  See
section 9.7.2.

The second of these is still wrong, though, since parentheses are *not*
literals in SIMILAR TO.  Will fix.

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

[HACKERS] release notes - issue

[Pavel Stehule]

Hello

PL/pgSQL functions using RETURNS QUERY or RECORD types no longer
always need to be rebuilt after adding or dropping a column for the
related tables.

I thing, so this isn't correct. When you dropped column, then you had
to rebuild table  - rebuild related function had no effect.

Regards
Pavel Stehule

-- 
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] Release notes introductory text

[Kevin Grittner]

 On Thu, Oct 18, 2007 at 12:34 AM, in message
[EMAIL PROTECTED], Bruce Momjian [EMAIL PROTECTED] wrote:

 This release represents a major leap forward for PostgreSQL by adding
 significant new functionality and performance enhancements. This was
 made possible by a growing community that has dramatically accelerated
 the pace of development. This release adds the follow major
 capabilities:
 
If we want to have a short intro to promote the new release,
this sounds good to me.
 
-Kevin
 



---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Release notes introductory text

[Bruce Momjian]

D'Arcy J.M. Cain wrote:
 On Thu, 11 Oct 2007 16:34:14 -0400 (EDT)
 Bruce Momjian [EMAIL PROTECTED] wrote:
  Kevin Grittner wrote:
productnamePostgreSQL/. Many complex ideas that normally take years
to implement were added rapidly to this release by our development team.

   You do realize that this will make many managers very reluctant to adopt
   it before it has settled in for many months, right?

   If the goal is to provide fair warning of a high-than-usual-risk
   release, you've got it covered.
  
  No, that was not the intent. The indent was to say we got a lot done in
  one year.  You have a suggestion?
 
 What if you changed were added rapidly to were quickly brought to
 maturity or something like that?

Updated text is:

This release represents a major leap forward for PostgreSQL by adding
significant new functionality and performance enhancements. This was
made possible by a growing community that has dramatically accelerated
the pace of development. This release adds the follow major
capabilities:

-- 
  Bruce Momjian  [EMAIL PROTECTED]http://momjian.us
  EnterpriseDB http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Release notes introductory text

[rm_rs]

Kevin Grittner wrote:

How exactly do you expect the software to get from a .0 to a .1 release,
or to have addressed the bugs that might bite you when it does get to .1,
if you aren't helping to test it?
  

In most environments I've seen, developer and QA systems don't hesitate
to move to .0 releases (or even beta).   I agree with Joshua that it's
nerve wracking to move _production_ systems to .0 releases from most
software vendors.

 
My philosophy is that the final QA environment should be as close to

the production environment as can be arranged, but that difference in
the development and initial test environments contribute to
robustness.
  

Sorry if I implied otherwise - I was assuming an environment
where QA has multiple environments; one of which clearly
should be the same as production.


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

Re: [HACKERS] Release notes introductory text

[Kevin Grittner]

 On Fri, Oct 12, 2007 at 12:37 PM, in message
[EMAIL PROTECTED], Ron Mayer
[EMAIL PROTECTED] wrote: 
 Tom Lane wrote:
 Joshua D. Drake [EMAIL PROTECTED] writes:
 With respect to you Kevin, your managers should wait. You don't
 install .0 releases of any software into production without months
 of testing. At which point, normally a .1 release has come out anyway.
 
All generalities are false.
 
Everyone needs to assess the risks and benefits for their own
environment, and figure out how close the can comfortably be to the
bleeding edge on any new technology.
 
We have been able to exercise not only .0 but RC and beta releases in
production because we have central servers holding consolidated
copies of the various distributed originals; with multiple copies of
these databases.  So we have redundancy in two dimensions, not to
mention backups of the redundant databases and two parallel backup
strategies for the original data.  And we synchronize the originals
to the copies during any slack time, and investigate any
discrepancies.  If the release seems stable enough, we'll put one copy
of the live redundant system at risk on beta or RC.
 
Is this testing or production?  I guess you could argue the semantics
either way.  Of course we do some load tests by replaying the
production HTTP request stream through test renderers; but it's being
fed 24/7 from a production environment, and we've been known to use
it for ad hoc queries.  I think we've even load-shifted the web site
over to it briefly to perform maintenance on the other servers.
 
 How exactly do you expect the software to get from a .0 to a .1 release,
 or to have addressed the bugs that might bite you when it does get to .1,
 if you aren't helping to test it?
 
 In most environments I've seen, developer and QA systems don't hesitate
 to move to .0 releases (or even beta).   I agree with Joshua that it's
 nerve wracking to move _production_ systems to .0 releases from most
 software vendors.
 
My philosophy is that the final QA environment should be as close to
the production environment as can be arranged, but that difference in
the development and initial test environments contribute to
robustness.
 
-Kevin
 


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Release notes introductory text

[Simon Riggs]

On Thu, 2007-10-11 at 17:46 -0400, Tom Lane wrote:
 Bruce Momjian [EMAIL PROTECTED] writes:
  Kevin Grittner wrote:
  If the goal is to provide fair warning of a high-than-usual-risk
  release, you've got it covered.
 
  No, that was not the intent. The indent was to say we got a lot done in
  one year.  You have a suggestion?
 
 Yeah: take the entire paragraph out again.  I concur with Neil that
 it's nothing but marketing fluff, and inaccurate fluff at that.

I think it is important that we are up beat about what we have achieved,
but perhaps we should avoid opinions in the release notes.

Perhaps it should be part of the press release?

We should say that the release notes get discussed on -hackers and the
press releases get discussed on -advocacy. That way the scope is clear
and we can keep the marketing at arms length from the engineering. I
think we need both, but in appropriate places.

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Release notes introductory text

[Magnus Hagander]

On Fri, Oct 12, 2007 at 07:51:13AM +0100, Simon Riggs wrote:
 On Thu, 2007-10-11 at 17:46 -0400, Tom Lane wrote:
  Bruce Momjian [EMAIL PROTECTED] writes:
   Kevin Grittner wrote:
   If the goal is to provide fair warning of a high-than-usual-risk
   release, you've got it covered.
  
   No, that was not the intent. The indent was to say we got a lot done in
   one year.  You have a suggestion?
  
  Yeah: take the entire paragraph out again.  I concur with Neil that
  it's nothing but marketing fluff, and inaccurate fluff at that.
 
 I think it is important that we are up beat about what we have achieved,
 but perhaps we should avoid opinions in the release notes.
 
 Perhaps it should be part of the press release?

It certainly sounds a lot more like press release than release notes to me...

//Magnus

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Release notes introductory text

[Ron Mayer]

Tom Lane wrote:
 Joshua D. Drake [EMAIL PROTECTED] writes:
 With respect to you Kevin, your managers should wait. You don't
 install .0 releases of any software into production without months
 of testing. At which point, normally a .1 release has come out anyway.
 
 How exactly do you expect the software to get from a .0 to a .1 release,
 or to have addressed the bugs that might bite you when it does get to .1,
 if you aren't helping to test it?

In most environments I've seen, developer and QA systems don't hesitate
to move to .0 releases (or even beta).   I agree with Joshua that it's
nerve wracking to move _production_ systems to .0 releases from most
software vendors.

 Now I realize that you did say test above, but way too often I see
 this sort of argument as a justification for doing nothing and expecting
 somebody else to fix it.

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

[HACKERS] Release notes introductory text

[Bruce Momjian]

[ BCC to docs and hackers.  Sorry this seems like the only logical way
to do this.]

I have added the following introductory paragraph to the release notes:

This release represents a major leap forward by adding significant new
functionality and performance enhancements to
productnamePostgreSQL/. Many complex ideas that normally take years
to implement were added rapidly to this release by our development team.
This release starts productnamePostgreSQL/ on a trajectory moving
beyond feature-parity with other database systems to a time when
productnamePostgreSQL/ will be a technology leader in the database
field. Major new capabilities in this release include:

The full release text with my edits to major and migration sections
is included:

http://momjian.us/main/writings/pgsql/sgml/release-8-3.html

Comments?

-- 
  Bruce Momjian  [EMAIL PROTECTED]http://momjian.us
  EnterpriseDB http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [HACKERS] Release notes introductory text

[Kevin Grittner]

 On Thu, Oct 11, 2007 at  3:04 PM, in message
[EMAIL PROTECTED], Bruce Momjian [EMAIL PROTECTED] wrote:
 
 This release represents a major leap forward by adding significant new
 functionality and performance enhancements to
 productnamePostgreSQL/. Many complex ideas that normally take years
 to implement were added rapidly to this release by our development team.
 
You do realize that this will make many managers very reluctant to adopt
it before it has settled in for many months, right?
 
If the goal is to provide fair warning of a high-than-usual-risk
release, you've got it covered.
 
-Kevin
 



---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

Re: [HACKERS] Release notes introductory text

[Bruce Momjian]

Kevin Grittner wrote:
  On Thu, Oct 11, 2007 at  3:04 PM, in message
 [EMAIL PROTECTED], Bruce Momjian [EMAIL PROTECTED] wrote:
  
  This release represents a major leap forward by adding significant new
  functionality and performance enhancements to
  productnamePostgreSQL/. Many complex ideas that normally take years
  to implement were added rapidly to this release by our development team.
  
 You do realize that this will make many managers very reluctant to adopt
 it before it has settled in for many months, right?
  
 If the goal is to provide fair warning of a high-than-usual-risk
 release, you've got it covered.

No, that was not the intent. The indent was to say we got a lot done in
one year.  You have a suggestion?

-- 
  Bruce Momjian  [EMAIL PROTECTED]http://momjian.us
  EnterpriseDB http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Release notes introductory text

[D'Arcy J.M. Cain]

On Thu, 11 Oct 2007 16:34:14 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
 Kevin Grittner wrote:
   productnamePostgreSQL/. Many complex ideas that normally take years
   to implement were added rapidly to this release by our development team.
   
  You do realize that this will make many managers very reluctant to adopt
  it before it has settled in for many months, right?
   
  If the goal is to provide fair warning of a high-than-usual-risk
  release, you've got it covered.
 
 No, that was not the intent. The indent was to say we got a lot done in
 one year.  You have a suggestion?

What if you changed were added rapidly to were quickly brought to
maturity or something like that?

-- 
D'Arcy J.M. Cain [EMAIL PROTECTED] |  Democracy is three wolves
http://www.druid.net/darcy/|  and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP)   |  what's for dinner.

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Release notes introductory text

[Neil Conway]

On Thu, 2007-10-11 at 16:04 -0400, Bruce Momjian wrote:
 I have added the following introductory paragraph to the release notes:
 
   This release represents a major leap forward by adding significant new
   functionality and performance enhancements to
   productnamePostgreSQL/. Many complex ideas that normally take years
   to implement were added rapidly to this release by our development team.
   This release starts productnamePostgreSQL/ on a trajectory moving
   beyond feature-parity with other database systems to a time when
   productnamePostgreSQL/ will be a technology leader in the database
   field.

Frankly, this sounds like empty hyperbole to me. There is a LOT of work
left to do before we reach feature parity with the major players, let
alone become a technology leader in the database field. I would
personally vote for just saying that this release brings with it a lot
of useful new features and performance improvements, and leave it up to
the reader to decide whether we're on a trajectory moving beyond
feature-parity.

If you want to compare where we are with the major players, I think it
would be more accurate to say that we're doing fairly well on OLTP
oriented features, but there is a lot of work left on OLAP
functionality.

-Neil



---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Release notes introductory text

[Andrew Hammond]

On 10/11/07, Bruce Momjian [EMAIL PROTECTED] wrote:

 Kevin Grittner wrote:
   On Thu, Oct 11, 2007 at  3:04 PM, in message
  [EMAIL PROTECTED], Bruce Momjian [EMAIL PROTECTED]
 wrote:
 
   This release represents a major leap forward by adding significant new
   functionality and performance enhancements to
   productnamePostgreSQL/. Many complex ideas that normally take
 years
   to implement were added rapidly to this release by our development
 team.
 
  You do realize that this will make many managers very reluctant to adopt
  it before it has settled in for many months, right?
 
  If the goal is to provide fair warning of a high-than-usual-risk
  release, you've got it covered.

 No, that was not the intent. The indent was to say we got a lot done in
 one year.  You have a suggestion?


Well, a number of these were bumped from 8.2, so it might be a good idea to
go with something like complex improvements long under development have
come to fruition. For the reason suggested above, I don't think it's a
great idea to try to emphasize the impressive speed with which some of these
features have actually been implemented. I don't know that there's any
credible way to tell people that although these things were done quickly
they were also done with the exceptional care and attention to detail for
which the PostgreSQL development community is famous.

I really like your wording about how we're going beyond feature parity.
That's exactly the kind of stance for which the World's Most Advanced Open
Source Database ought to be aiming. As long as we can avoid the negative
connotations associated with experimental.

Andrew

Re: [HACKERS] Release notes introductory text

[Tom Lane]

Bruce Momjian [EMAIL PROTECTED] writes:
 Kevin Grittner wrote:
 If the goal is to provide fair warning of a high-than-usual-risk
 release, you've got it covered.

 No, that was not the intent. The indent was to say we got a lot done in
 one year.  You have a suggestion?

Yeah: take the entire paragraph out again.  I concur with Neil that
it's nothing but marketing fluff, and inaccurate fluff at that.

regards, tom lane

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Release notes introductory text

[Kevin Grittner]

 On Thu, Oct 11, 2007 at  3:34 PM, in message
[EMAIL PROTECTED], Bruce Momjian [EMAIL PROTECTED] wrote:

 The indent was to say we got a lot done in
 one year.  You have a suggestion?
 
My suggestion would be to stay away from statements about the speed
of development and focus on the user benefits of the release.
 
Before my previous post I asked a manager to read the statement and
let me know what he thought, and he said that it sounds great if it
works but that it sounded like something was being rushed into
production, which in his experience always meant a lot of bugs.  I
think everyone who contributed to these major improvements deserves
to be proud of their productivity, but it's hard to talk about that
in public without generating the wrong impression.
 
Come to think of it, a statements about high productivity, valuable
contributions, and community effort all spin OK.  I would stay away
from heroic effort, though, as it is used in a negative way in
some agile programming documents.
 
Again, above all, focus on answering the question:
 
What benefit do I get from moving to this release?
 
-Kevin
 



---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Release notes introductory text

[Joshua D. Drake]

On Thu, 11 Oct 2007 15:26:43 -0500
Kevin Grittner [EMAIL PROTECTED] wrote:

  This release represents a major leap forward by adding significant
  new functionality and performance enhancements to
  productnamePostgreSQL/. Many complex ideas that normally take
  years to implement were added rapidly to this release by our
  development team.
  
 You do realize that this will make many managers very reluctant to
 adopt it before it has settled in for many months, right?

With respect to you Kevin, your managers should wait. You don't
install .0 releases of any software into production without months
of testing. At which point, normally a .1 release has come out anyway.

Sincerely,

Joshua D. Drake


  
 If the goal is to provide fair warning of a high-than-usual-risk
 release, you've got it covered.
  
 -Kevin
  
 
 
 
 ---(end of
 broadcast)--- TIP 7: You can help support the
 PostgreSQL project by donating at
 
 http://www.postgresql.org/about/donate
 


-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564   24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997  http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/



signature.asc
Description: PGP signature

Re: [HACKERS] Release notes introductory text

[Michael Glaesemann]

On Oct 11, 2007, at 18:51 , Joshua D. Drake wrote:


With respect to you Kevin, your managers should wait. You don't
install .0 releases of any software into production without months
of testing. At which point, normally a .1 release has come out anyway.


At the same time, an open source project such as PostgreSQL provides  
advantages here, in that preliminary testing can be performed during  
the development of the release, verified, of course, after the  
release has been made.


Michael Glaesemann
grzm seespotcode net




PGP.sig
Description: This is a digitally signed message part

Re: [HACKERS] Release notes introductory text

[Tom Lane]

Joshua D. Drake [EMAIL PROTECTED] writes:
 With respect to you Kevin, your managers should wait. You don't
 install .0 releases of any software into production without months
 of testing. At which point, normally a .1 release has come out anyway.

How exactly do you expect the software to get from a .0 to a .1 release,
or to have addressed the bugs that might bite you when it does get to .1,
if you aren't helping to test it?

Now I realize that you did say test above, but way too often I see
this sort of argument as a justification for doing nothing and expecting
somebody else to fix it.

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Release notes introductory text

[Joshua D. Drake]

On Thu, 11 Oct 2007 21:31:20 -0400
Tom Lane [EMAIL PROTECTED] wrote:

 Joshua D. Drake [EMAIL PROTECTED] writes:
  With respect to you Kevin, your managers should wait. You don't

 
 Now I realize that you did say test above, but way too often I see
 this sort of argument as a justification for doing nothing and
 expecting somebody else to fix it.

Tom, I get paid to deal with it, remember? I hardly want to do nothing
and expect someone else to fix it. I wouldn't get paid :) I just believe
that the sanest course of action with my customers data, is the
conservative course of action.

That means, testing, before, during and after release. It also means
unless there is something extremely pertinent (I have several customers
threatening to fly out and strangle me personally if I don't upgrade
them to 8.3 ASAP because of HOT), I won't upgrade them until I have
confidence in production deployment.

There are varying degrees of need. Some will need 8.3 as soon as
possible, but even those I would professionally suggest they put
against a test harness of production data. Otherwise they are looking
for trouble and they are may or may not find it.

When one has been doing this as long as I have, with as many postgresql
deployments as I have... you get gun shy and only upgrade when you
must. That means dot releases, or specific business value.

I have many, many customers that will be on 8.1 for a very, very long
time to come. I will concede that it is a very hard argument for
*anyone* to be running less than 8.1.

Sincerely,

Joshua D. Drake


 
   regards, tom lane
 
 ---(end of
 broadcast)--- TIP 4: Have you searched our
 list archives?
 
http://archives.postgresql.org
 


-- 

  === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564   24x7/Emergency: +1.800.492.2240
PostgreSQL solutions since 1997  http://www.commandprompt.com/
UNIQUE NOT NULL
Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/



signature.asc
Description: PGP signature

Re: [HACKERS] Release Notes Overview

[Bruce Momjian]

Gregory Stark wrote:
 
 Simon Riggs [EMAIL PROTECTED] writes:
 
  Asynchronous Commit allows some transactions to commit faster than
  others, offering a trade-off between performance and durability for
  specific transaction types only
 
 A lot of users will be confused about what asynchronous commit does. I think
 it's important to be consistently precise when describing it. 
 
 It doesn't allow commits to be any faster, what it does is allow clients to
 start a new transaction and continue working without waiting for their
 previous commit to complete. Saying something like This allows high volumes
 of short transactions such as typical web sites to run more efficiently and
 with fewer connections might also help clarify the use case it helps.

Well, logically the commit does happen faster in that your transaction
and others see the commit.  It is just durability that is delayed.

-- 
  Bruce Momjian  [EMAIL PROTECTED]http://momjian.us
  EnterpriseDB http://postgres.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate

[HACKERS] Release Notes Overview

[Simon Riggs]

My suggested edit of the Overview section of the Release Notes. The
emphasis is on user-noticeable features, so some of the major internal
changes are lower down the list. Some items have been removed or placed
below the performance features.


New data types for SQL/XML, enum and uuid types

Updateable Cursors, plus support in PL/pgSQL. PostgreSQL now supports
all major items of Core SQL:2003 compatibility.

Full text Search is now a built-in feature, so  is easier/better

Asynchronous Commit allows some transactions to commit faster than
others, offering a trade-off between performance and durability for
specific transaction types only

Database Size reductions both per-row and per-field

Additional security features: GSSAPI/SSPI and easier to implement
security-definer functions using per function SET parameters

New ORDER BY ... NULLS FIRST/LAST option and matching support for
indexes allows easier migration of applications from other RDBMS

Better scalability and more consistent response times come from
systematic removal of internal contention points within the server

Performance improvements in many important workloads

- update-intensive workloads now avoid index inserts via a new internal
mechanism known as HOT, plus multiple concurrent auto-vacuum processes
maintain the database more consistently

- initial data loads now avoid writing WAL, plus all data loads use less
CPU than previously

- large table scans by optimising cache usage and allowing multiple
synchronous scans to reuse the same data, avoiding I/O

- short read-only transactions give reduced costs and higher scalability
using lazy transactionid assignment 

Tracking of internal activity has many additional features, improving
your ability to design, manage and maintain the database

Self-adjusting background writer helps write-intensive workloads

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Release Notes Overview

[Gregory Stark]

Simon Riggs [EMAIL PROTECTED] writes:

 Asynchronous Commit allows some transactions to commit faster than
 others, offering a trade-off between performance and durability for
 specific transaction types only

A lot of users will be confused about what asynchronous commit does. I think
it's important to be consistently precise when describing it. 

It doesn't allow commits to be any faster, what it does is allow clients to
start a new transaction and continue working without waiting for their
previous commit to complete. Saying something like This allows high volumes
of short transactions such as typical web sites to run more efficiently and
with fewer connections might also help clarify the use case it helps.

-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Release Notes Overview

[Simon Riggs]

On Fri, 2007-10-05 at 11:24 +0100, Gregory Stark wrote:
 Simon Riggs [EMAIL PROTECTED] writes:
 
  Asynchronous Commit allows some transactions to commit faster than
  others, offering a trade-off between performance and durability for
  specific transaction types only
 
 A lot of users will be confused about what asynchronous commit does. I think
 it's important to be consistently precise when describing it. 
 
 It doesn't allow commits to be any faster, what it does is allow clients to
 start a new transaction and continue working without waiting for their
 previous commit to complete. Saying something like This allows high volumes
 of short transactions such as typical web sites to run more efficiently and
 with fewer connections might also help clarify the use case it helps.

The general shape of the overview was what I was looking at. 

I agree with your specific comment.

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Markus Schaber]

Hi, Bruce,

Bruce Momjian wrote:

   listitem
para
 Allow inheritance to be removed from tables
/para
   /listitem

I'd enhance that to Allow table inheritance relationships to be defined
for and removed from pre-existing tables.

HTH,
Markus

-- 
Markus Schaber | Logical TrackingTracing International AG
Dipl. Inf. | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Bruce Momjian]

Markus Schaber wrote:
-- Start of PGP signed section.
 Hi, Bruce,
 
 Bruce Momjian wrote:
 
listitem
 para
  Allow inheritance to be removed from tables
 /para
/listitem
 
 I'd enhance that to Allow table inheritance relationships to be defined
 for and removed from pre-existing tables.

Good point.  Updated wording:

Allow table inheritance to be added and removed from
pre-existing tables   

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Markus Schaber]

Hi, Bruce,

Bruce Momjian wrote:
 Allow inheritance to be removed from tables
 I'd enhance that to Allow table inheritance relationships to be defined
 for and removed from pre-existing tables.
 
 Good point.  Updated wording:
 
 Allow table inheritance to be added and removed from
   pre-existing tables   

Agree, that's excellent.


Thanks,
Markus
-- 
Markus Schaber | Logical TrackingTracing International AG
Dipl. Inf. | Software Development GIS

Fight against software patents in Europe! www.ffii.org
www.nosoftwarepatents.org



signature.asc
Description: OpenPGP digital signature

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Bruce Momjian]

Andrew Dunstan wrote:
 Bruce Momjian wrote:
  I created a major features list for 8.2 and put it into CVS.  Instead of
  going into detail (meaning the item would not appear in the Changes
  section below, I just highlighted some of the big stuff, and was
  purposely vague about the details, so people just have an overview of
  what is below.
 
  Let me know how it looks.

 
 
 Some of these just look rather vague. For example:
 
 *
 
   More control over creating/dropping objects and inheritance
 
 
 If I did not know what the features were, that item would convey nothing 
 to me. The fact that you can add/drop the inheritance characteristics of 
 a table after its creation isn't something I would just lump under more 
 control - it's a major new feature that will possibly revolutionize the 
 way people use inheritance, especially for partitioning.

OK, split items up:

  listitem
   para
More control over creating and dropping objects
   /para
  /listitem

  listitem
   para
Allow inheritance to be removed from tables
   /para
  /listitem

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Jim C. Nasby]

On Fri, Sep 22, 2006 at 12:59:36PM -0700, Joe Conway wrote:
 Andrew Sullivan wrote:
 On Thu, Sep 21, 2006 at 03:05:36PM -0500, Jim C. Nasby wrote:
 
 Regardless, I think we should include a section of major new
 projects/developments from pgFoundry, because they ultimately make
 PostgreSQL a more useful database. Maybe this list should only be in the
 
 I like that.  New enhancement products or something?
 
enhancement products makes me think if Encyte and the like... :P Maybe
add-ons would be better?

 In that case, what about things on gborg too? I just updated PL/R for 
 8.2 compatibility (and finally changed the status from alpha to beta).
 
 BTW, I'm happy to move PL/R over to pgFoundry, but became a little 
 concerned about doing that after seeing the lengthy thread regarding 
 pgFoundry concerns (but admittedly, I didn't have time to read the 
 thread in detail, because I'm back over in Germany on a long business 
 trip again).

I didn't mention gforge since it'd depricated, but I don't see an issue
with listing any add-on projects, no matter where they're hosted. For
example, didn't pgAdmin just add support for Slony? That's something
worth mentioning.
-- 
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Dave Page]

 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Jim C. Nasby
 Sent: 25 September 2006 15:03
 To: Joe Conway
 Cc: Andrew Sullivan; pgsql-hackers@postgresql.org
 Subject: Re: [HACKERS] Release Notes: Major Changes in 8.2
 
 For
 example, didn't pgAdmin just add support for Slony? That's something
 worth mentioning.

That was our last major release. You can see what will be in 1.6 at
http://www.pgadmin.org/development/changelog.php

Regards, Dave

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Release Notes: Major Changes in 8.2

[David Fetter]

On Mon, Sep 25, 2006 at 03:10:39PM +0100, Dave Page wrote:
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Jim C. Nasby
  
  For example, didn't pgAdmin just add support for Slony? That's
  something worth mentioning.
 
 That was our last major release. You can see what will be in 1.6 at
 http://www.pgadmin.org/development/changelog.php

Could you clarify this a bit?  As far as I can tell, it's not possible
to set up slony initially with pgadmin 1.4.latest.  Has this changed
in 1.6?

Cheers,
D

-- 
David Fetter [EMAIL PROTECTED] http://fetter.org/
phone: +1 415 235 3778AIM: dfetter666
  Skype: davidfetter

Remember to vote!

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Dave Page]

 

 -Original Message-
 From: David Fetter [mailto:[EMAIL PROTECTED] 
 Sent: 25 September 2006 16:57
 To: Dave Page
 Cc: Jim C. Nasby; Joe Conway; Andrew Sullivan; 
 pgsql-hackers@postgresql.org
 Subject: Re: [HACKERS] Release Notes: Major Changes in 8.2
 
 On Mon, Sep 25, 2006 at 03:10:39PM +0100, Dave Page wrote:
   From: [EMAIL PROTECTED] 
   [mailto:[EMAIL PROTECTED] On Behalf Of 
 Jim C. Nasby
   
   For example, didn't pgAdmin just add support for Slony? That's
   something worth mentioning.
  
  That was our last major release. You can see what will be in 1.6 at
  http://www.pgadmin.org/development/changelog.php
 
 Could you clarify this a bit?  As far as I can tell, it's not possible
 to set up slony initially with pgadmin 1.4.latest.  Has this changed
 in 1.6?

The only change to the Slony support in 1.6 is a minor update to allow
it to initialise a Slony 1.2 cluster (the version number needs to be
inserted into the slony1_funcs script now). 

The only parts of the initial setup that pgAdmin doesn't do are the
installation of the Slony shared libraries, or the copying of the schema
(actually, pgAdmin can do this - it just doesn't do it automagically.
Just backup and restore the relevant bits of your schema on the slave
nodes).

All the Slony support in pgAdmin was written as part of a contract with
a Japanese company (SKC) to port Slony to Windows - that work was
finished almost a year ago.

Regards, Dave


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Josh Berkus]

Folks,


On Thu, Sep 21, 2006 at 03:05:36PM -0500, Jim C. Nasby wrote:

Regardless, I think we should include a section of major new
projects/developments from pgFoundry, because they ultimately make
PostgreSQL a more useful database. Maybe this list should only be in the


I like that.  New enhancement products or something?

A



If you're following the release drafting in pgsql-advocacy, you'll see 
that we're planning on including a section about pgfoundry projects in 
the extended release on the web, or press kit.  So far, I've listed 
pgPool, PL/Java and Full Disjunctions; I'm not sure what else to list. 
Suggestions welcome.


--Josh Berkus

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Andrew Sullivan]

On Fri, Sep 22, 2006 at 12:59:36PM -0700, Joe Conway wrote:
 
 In that case, what about things on gborg too?

Yes, same idea.  I don't care where the project _lives_; the
important thing is its integration with PostgreSQL (and its quality).

A

-- 
Andrew Sullivan  | [EMAIL PROTECTED]
When my information changes, I alter my conclusions.  What do you do sir?
--attr. John Maynard Keynes

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Simon Riggs]

On Thu, 2006-09-21 at 21:45 -0400, Bruce Momjian wrote:

 Let me know how it looks.

Very Good



Very last, Minor change thoughts:

  * Continuous archiving enhancements 

change: Warm Standby enhancements

The improvements to Continuous Archiving relate directly to the
creation of Warm Standby servers, so it would be better to
mention Warm Standby, not Continuous Archiving (and definitely
not PITR)

  * Monitoring and logging additions 

add to end of line: improve performance tuning capability

  * COPY support for SELECT statements 

change: COPY TO support ...

add to end of line: enhances data unload

  * Array and aggregate improvements 

add  to end of line: , plus SQL:2003 statistical functions

-- 
  Simon Riggs 
  EnterpriseDB   http://www.enterprisedb.com


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Bruce Momjian]

Great, all added.

---

Simon Riggs wrote:
 On Thu, 2006-09-21 at 21:45 -0400, Bruce Momjian wrote:
 
  Let me know how it looks.
 
 Very Good
 
 
 
 Very last, Minor change thoughts:
 
   * Continuous archiving enhancements 
 
 change: Warm Standby enhancements
 
 The improvements to Continuous Archiving relate directly to the
 creation of Warm Standby servers, so it would be better to
 mention Warm Standby, not Continuous Archiving (and definitely
 not PITR)
 
   * Monitoring and logging additions 
 
 add to end of line: improve performance tuning capability
 
   * COPY support for SELECT statements 
 
 change: COPY TO support ...
 
 add to end of line: enhances data unload
 
   * Array and aggregate improvements 
 
 add  to end of line: , plus SQL:2003 statistical functions
 
 -- 
   Simon Riggs 
   EnterpriseDB   http://www.enterprisedb.com
 
 
 ---(end of broadcast)---
 TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Andrew Sullivan]

On Thu, Sep 21, 2006 at 03:05:36PM -0500, Jim C. Nasby wrote:
 Regardless, I think we should include a section of major new
 projects/developments from pgFoundry, because they ultimately make
 PostgreSQL a more useful database. Maybe this list should only be in the

I like that.  New enhancement products or something?

A

-- 
Andrew Sullivan  | [EMAIL PROTECTED]
I remember when computers were frustrating because they *did* exactly what 
you told them to.  That actually seems sort of quaint now.
--J.D. Baldwin

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Andrew Dunstan]

Bruce Momjian wrote:

I created a major features list for 8.2 and put it into CVS.  Instead of
going into detail (meaning the item would not appear in the Changes
section below, I just highlighted some of the big stuff, and was
purposely vague about the details, so people just have an overview of
what is below.

Let me know how it looks.
  



Some of these just look rather vague. For example:

   *

 More control over creating/dropping objects and inheritance


If I did not know what the features were, that item would convey nothing 
to me. The fact that you can add/drop the inheritance characteristics of 
a table after its creation isn't something I would just lump under more 
control - it's a major new feature that will possibly revolutionize the 
way people use inheritance, especially for partitioning.


cheers

andrew




---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Joe Conway]

Andrew Sullivan wrote:

On Thu, Sep 21, 2006 at 03:05:36PM -0500, Jim C. Nasby wrote:


Regardless, I think we should include a section of major new
projects/developments from pgFoundry, because they ultimately make
PostgreSQL a more useful database. Maybe this list should only be in the


I like that.  New enhancement products or something?


In that case, what about things on gborg too? I just updated PL/R for 
8.2 compatibility (and finally changed the status from alpha to beta).


BTW, I'm happy to move PL/R over to pgFoundry, but became a little 
concerned about doing that after seeing the lengthy thread regarding 
pgFoundry concerns (but admittedly, I didn't have time to read the 
thread in detail, because I'm back over in Germany on a long business 
trip again).


Joe


---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Zdenek Kotala]

Simon Riggs napsal(a):



Improved monitoring and performance tuning (Tom, Bruce, Greg, Larry)

Overhead of statistics collection has been considerably reduced and new
statistics and system information is available. Better query logging
improves diagnostics and especially performance tuning. Server now
includes DTrace support. Indexes can now also be created CONCURRENTLY,
allowing application tuning without effecting server availability.



You forgot to Robert Lor - author of DTrace support.

Zdenek

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Simon Riggs]

On Wed, 2006-09-20 at 23:22 -0400, Bruce Momjian wrote:

 Usually the major items just jump out of the release list.  In this
 case, nothing really jumped out, and I felt if I listed sereral, it was
 going to look weak because they were not big things, so I figured I
 would just go with the broad list.

Look back at the 7.4 release notes as a comparison. I think 8.0 was such
a milestone release we tend to judge ourselves by that and maybe feel
like the pace has slackened. IMHO, it has accelerated. We hit the lower
hanging fruit first, so early features were major items; later items
seem smaller and less important by comparison, especially when completed
by a team rather than a few individuals.

I don't think it matters whether the new features originated as a single
patch or as a stream of smaller patches. The end result is a major
improvement in a specific area. Picking one area I'm more familiar with,
sort performance was increased over many patches by many people, but the
original objective of making a step-change in that area *has* been
achieved (even if there are some additional gains still to be had for
certain narrower use-cases).

The role of the Major changes section is to provide a summary for
administrators who need to understand what a new release will give them
and make a cost/benefit judgement. We want people to understand the good
work that has been done and that does involve some filtering and
summarization, and its possibly true that it is harder in this release
than others. 

We need a Major changes section: People don't read the detail: sysadmins
are too busy these days. If there are no major features listed, people
will assume there are none and say oh its just a bug fix release. If
we aren't encouraging people to upgrade, why release at all? Maybe
people only upgrade every other release - if so, we'll get all of the
8.0 upgraders.

Improving scalability in 8.1 was great. Improving it again in 8.2 is
amazing and we should tell people, even if it sounds somewhat boring
because we did it last time as well. I think: again, wow, this software
is going places. Personally, I'll be ecstatic if we can do that again
for 8.3...

 Or perhaps we can do more broad-stroke list items, like monitoring or
 performance, as listed below.

Whether we like my list or not, I think such a grouped list should
exist. I'm mainly seeking to persuade you on that point and would be
comfortable even if you came up with a different grouped list.

Seeing a list of names after a topic emphasises the community
development process. In some cases, there was a stated objective and
that has been achieved. In other cases there was a community-driven move
in directions maybe we didn't predict. In the latter case, surely it is
the strength of open source that evolution works so well and really does
produce noticeably major changes. The changes in monitoring and tuning
tools is an excellent example: many smaller changes making a significant
improvement.

Please vote in favour of a Major Changes section.

-- 
  Simon Riggs 
  EnterpriseDB   http://www.enterprisedb.com


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Bruce Momjian]

Josh Berkus wrote:
 Bruce,
 
 What happened to PL/pgSQL debugging?  Did it die?

The debuggers is going to be on pgfoundry, if it isn't there already. 
The idea is that it would be loadable for 8.2, work out all the bugs,
and perhaps included in 8.3.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Bruce Momjian]

OK, I will work it.

---

Simon Riggs wrote:
 On Wed, 2006-09-20 at 23:22 -0400, Bruce Momjian wrote:
 
  Usually the major items just jump out of the release list.  In this
  case, nothing really jumped out, and I felt if I listed sereral, it was
  going to look weak because they were not big things, so I figured I
  would just go with the broad list.
 
 Look back at the 7.4 release notes as a comparison. I think 8.0 was such
 a milestone release we tend to judge ourselves by that and maybe feel
 like the pace has slackened. IMHO, it has accelerated. We hit the lower
 hanging fruit first, so early features were major items; later items
 seem smaller and less important by comparison, especially when completed
 by a team rather than a few individuals.
 
 I don't think it matters whether the new features originated as a single
 patch or as a stream of smaller patches. The end result is a major
 improvement in a specific area. Picking one area I'm more familiar with,
 sort performance was increased over many patches by many people, but the
 original objective of making a step-change in that area *has* been
 achieved (even if there are some additional gains still to be had for
 certain narrower use-cases).
 
 The role of the Major changes section is to provide a summary for
 administrators who need to understand what a new release will give them
 and make a cost/benefit judgement. We want people to understand the good
 work that has been done and that does involve some filtering and
 summarization, and its possibly true that it is harder in this release
 than others. 
 
 We need a Major changes section: People don't read the detail: sysadmins
 are too busy these days. If there are no major features listed, people
 will assume there are none and say oh its just a bug fix release. If
 we aren't encouraging people to upgrade, why release at all? Maybe
 people only upgrade every other release - if so, we'll get all of the
 8.0 upgraders.
 
 Improving scalability in 8.1 was great. Improving it again in 8.2 is
 amazing and we should tell people, even if it sounds somewhat boring
 because we did it last time as well. I think: again, wow, this software
 is going places. Personally, I'll be ecstatic if we can do that again
 for 8.3...
 
  Or perhaps we can do more broad-stroke list items, like monitoring or
  performance, as listed below.
 
 Whether we like my list or not, I think such a grouped list should
 exist. I'm mainly seeking to persuade you on that point and would be
 comfortable even if you came up with a different grouped list.
 
 Seeing a list of names after a topic emphasises the community
 development process. In some cases, there was a stated objective and
 that has been achieved. In other cases there was a community-driven move
 in directions maybe we didn't predict. In the latter case, surely it is
 the strength of open source that evolution works so well and really does
 produce noticeably major changes. The changes in monitoring and tuning
 tools is an excellent example: many smaller changes making a significant
 improvement.
 
 Please vote in favour of a Major Changes section.
 
 -- 
   Simon Riggs 
   EnterpriseDB   http://www.enterprisedb.com
 
 
 ---(end of broadcast)---
 TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Dave Page]

 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian
 Sent: 21 September 2006 16:25
 To: Josh Berkus
 Cc: pgsql-hackers@postgresql.org; Simon Riggs
 Subject: Re: [HACKERS] Release Notes: Major Changes in 8.2
 
 Josh Berkus wrote:
  Bruce,
  
  What happened to PL/pgSQL debugging?  Did it die?
 
 The debuggers is going to be on pgfoundry, if it isn't there already. 
 The idea is that it would be loadable for 8.2, work out all the bugs,
 and perhaps included in 8.3.

We've also discussed bundling the GUI with pgAdmin for 1.8 (which will
be released with 8.3) so that idea could work out nicely.

Regards, Dave.

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Josh Berkus]

Bruce, All:

The debuggers is going to be on pgfoundry, if it isn't there already. 
The idea is that it would be loadable for 8.2, work out all the bugs,

and perhaps included in 8.3.



So, should I take this off the press list for 8.2 and save it for 8.3, 
when the feature will be actually useful?


Second question:  are the Advisory Locks actually a unique PostgreSQL 
feature, or are these something other databases already have?


--Josh Berkus


---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Jim C. Nasby]

On Thu, Sep 21, 2006 at 11:24:53AM -0400, Bruce Momjian wrote:
 Josh Berkus wrote:
  Bruce,
  
  What happened to PL/pgSQL debugging?  Did it die?
 
 The debuggers is going to be on pgfoundry, if it isn't there already. 
 The idea is that it would be loadable for 8.2, work out all the bugs,
 and perhaps included in 8.3.

But didn't we end up putting some hooks in the backend to make this
possible?

Regardless, I think we should include a section of major new
projects/developments from pgFoundry, because they ultimately make
PostgreSQL a more useful database. Maybe this list should only be in the
PR (and not the release notes)...
-- 
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Bruce Momjian]

Josh Berkus wrote:
 Bruce, All:
 
  The debuggers is going to be on pgfoundry, if it isn't there already. 
  The idea is that it would be loadable for 8.2, work out all the bugs,
  and perhaps included in 8.3.
  
 
 So, should I take this off the press list for 8.2 and save it for 8.3, 
 when the feature will be actually useful?

Yes, I think so.

 Second question:  are the Advisory Locks actually a unique PostgreSQL 
 feature, or are these something other databases already have?

Probably not unique.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Chris Browne]

[EMAIL PROTECTED] (Bruce Momjian) writes:
 Josh Berkus wrote:
 Bruce,
 
 What happened to PL/pgSQL debugging?  Did it die?

 The debuggers is going to be on pgfoundry, if it isn't there already. 
 The idea is that it would be loadable for 8.2, work out all the bugs,
 and perhaps included in 8.3.

If we now have the hooks in place, then it is surely worth saying so.
To then point people to pgFoundry for an add-on debugger application
seems pretty fair.
-- 
select 'cbbrowne' || '@' || 'cbbrowne.com';
http://linuxdatabases.info/info/finances.html
Rules of the Evil Overlord #133.  If I find my beautiful consort with
access to  my fortress has been  associating with the  hero, I'll have
her executed.  It's regrettable,  but new consorts  are easier  to get
than new fortresses  and maybe the next one will  pay attention at the
orientation meeting. http://www.eviloverlord.com/

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Karen Hill]

Simon Riggs wrote:


 SQL:2003 Analytical functions (Sergey, Tom, Neil)

   All statistical aggregate functions defined by SQL:2003 are now
 supported and user-defined aggregates now can take multiple columns as
 inputs.


Could this be a good starting point for SQL:2003 Window functions as
now the work on SQL:2003 statistical functions are done?  As
experienced postgres developers what would be your roadmap to implement
window functions?


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Bruce Momjian]

I created a major features list for 8.2 and put it into CVS.  Instead of
going into detail (meaning the item would not appear in the Changes
section below, I just highlighted some of the big stuff, and was
purposely vague about the details, so people just have an overview of
what is below.

Let me know how it looks.

Simon's list below looks good, but it really has a lot of details,
particuarly it goes into use-cases for many of the features, and in fact
goes into more detail that we even have in the release notes now.  Is
that what people want?  My concern is that if we push too much
information, it is hard to see the actual features, i.e. if we say, we
have feature X, and it is good for Y, Z, and Q do people remember Y and
Z and forget X?

Again, I don't want to be the person writing these release notes, so I
am looking for feedback, good or bad.

---

Simon Riggs wrote:
 I'd like to include a section on Major changes in this release at the
 top of the release notes, as has been done for at least the last 6 major
 releases. The notes below are one stab at that, for **discussion**. I've
 tried to arrange specific changes into groups... 
 
 
 Major changes in this release:
 
 Improved scalability and performance on multi-processor systems (Tom,
 Alvaro, Itagaki, Qingqing, Heikki)
 
   A variety of changes improves the performance of both sequential scans
 and index scans, as well as enhancing multi-processor scalability. The
 advanced query optimizer has also been further enhanced, allowing
 indexes and partitioning to be useful in more cases. 
 
 Improved utility and large query performance (Tom, Simon, Alon, Andreas)
 
   Large sorts will have typical performance increases of 100-300%,
 improving complex queries and creating new indexes. Loading times have
 also been reduced. Large queries, data loads, upgrades and restores will
 be considerably improved.
 
 Improved monitoring and performance tuning (Tom, Bruce, Greg, Larry)
 
   Overhead of statistics collection has been considerably reduced and new
 statistics and system information is available. Better query logging
 improves diagnostics and especially performance tuning. Server now
 includes DTrace support. Indexes can now also be created CONCURRENTLY,
 allowing application tuning without effecting server availability.
 
 Zero administration overhead now possible (Alvaro)
 
   With autovacuum enabled, all required vacuuming will now take place
 without administrator intervention enabling wider distribution of
 embedded databases.
 
 Improved defaults and configuration (Peter, Andrew)
 
   Installation defaults are now improved for many tunable memory
 parameters and these can now be specified in kB, MB and GB. 
 
 Warm Standby Servers for High Availability (Simon, Tom)
 
   Warm Standby servers can now be more easily configured and are
 appropriate in a wider range of circumstances than previously.
 
 Improved scalability and performance of text search: GIN and Tsearch2
 (Teodor, Oleg)
 
   New GIN indexes allow much larger text search indexes than were
 previously possible. TSearch2 has been enhanced and performance has also
 been greatly improved.
 
 Enhanced DML Functionality (Jonah, Joe, Tom, Susanne, Atsushi)
 
   INSERT/UPDATE/DELETE RETURNING and INSERT .. VALUES (), VALUES (),
 VALUES () allow more efficient application designs. Enhancements to
 UPDATE and DELETE allow additional constructs for clarity and ease of
 use.
 
 SQL:2003 Analytical functions (Sergey, Tom, Neil)
 
   All statistical aggregate functions defined by SQL:2003 are now
 supported and user-defined aggregates now can take multiple columns as
 inputs.
 
 -- 
   Simon Riggs 
   EnterpriseDB   http://www.enterprisedb.com
 
 
 ---(end of broadcast)---
 TIP 4: Have you searched our list archives?
 
http://archives.postgresql.org

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Release notes

[Bruce Momjian]

Thanks, done.

---

Alvaro Herrera wrote:
 Jim C. Nasby wrote:
  On Tue, Sep 19, 2006 at 09:37:39AM -0400, Bruce Momjian wrote:
   Jim C. Nasby wrote:
On Mon, Sep 18, 2006 at 06:47:02PM -0400, Bruce Momjian wrote:
  Both this and pg_prepared_statements are very useful for pooled
  connection setups.
  
  Should read Both of these are very useful...
 
 I don't think I can't change that because they are two separate bullet
 items.
 
Except it's refering to both items. Maybe the two items should just be
combined into one?
   
   Please post some combined wording, but I am afraid it will be too
   complicated to merge them.
  
  - Add pg_prepared_statements and pg_cursors system views to show prepared
  statements and open cursors.
  
  Both of these are very useful for pooled connection setups.
 
 - Add pg_prepared_statements ...
 
 - Add pg_cursors ...
   This, and pg_prepared_statements above, are both useful for ...
 
 -- 
 Alvaro Herrerahttp://www.CommandPrompt.com/
 PostgreSQL Replication, Consulting, Custom Development, 24x7 support

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

[HACKERS] Release Notes: Major Changes in 8.2

[Simon Riggs]

I'd like to include a section on Major changes in this release at the
top of the release notes, as has been done for at least the last 6 major
releases. The notes below are one stab at that, for **discussion**. I've
tried to arrange specific changes into groups... 


Major changes in this release:

Improved scalability and performance on multi-processor systems (Tom,
Alvaro, Itagaki, Qingqing, Heikki)

A variety of changes improves the performance of both sequential scans
and index scans, as well as enhancing multi-processor scalability. The
advanced query optimizer has also been further enhanced, allowing
indexes and partitioning to be useful in more cases. 

Improved utility and large query performance (Tom, Simon, Alon, Andreas)

Large sorts will have typical performance increases of 100-300%,
improving complex queries and creating new indexes. Loading times have
also been reduced. Large queries, data loads, upgrades and restores will
be considerably improved.

Improved monitoring and performance tuning (Tom, Bruce, Greg, Larry)

Overhead of statistics collection has been considerably reduced and new
statistics and system information is available. Better query logging
improves diagnostics and especially performance tuning. Server now
includes DTrace support. Indexes can now also be created CONCURRENTLY,
allowing application tuning without effecting server availability.

Zero administration overhead now possible (Alvaro)

With autovacuum enabled, all required vacuuming will now take place
without administrator intervention enabling wider distribution of
embedded databases.

Improved defaults and configuration (Peter, Andrew)

Installation defaults are now improved for many tunable memory
parameters and these can now be specified in kB, MB and GB. 

Warm Standby Servers for High Availability (Simon, Tom)

Warm Standby servers can now be more easily configured and are
appropriate in a wider range of circumstances than previously.

Improved scalability and performance of text search: GIN and Tsearch2
(Teodor, Oleg)

New GIN indexes allow much larger text search indexes than were
previously possible. TSearch2 has been enhanced and performance has also
been greatly improved.

Enhanced DML Functionality (Jonah, Joe, Tom, Susanne, Atsushi)

INSERT/UPDATE/DELETE RETURNING and INSERT .. VALUES (), VALUES (),
VALUES () allow more efficient application designs. Enhancements to
UPDATE and DELETE allow additional constructs for clarity and ease of
use.

SQL:2003 Analytical functions (Sergey, Tom, Neil)

All statistical aggregate functions defined by SQL:2003 are now
supported and user-defined aggregates now can take multiple columns as
inputs.

-- 
  Simon Riggs 
  EnterpriseDB   http://www.enterprisedb.com


---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Release notes

[Simon Riggs]

On Fri, 2006-09-15 at 15:37 -0400, Bruce Momjian wrote:
 I have completed my first pass over the release notes and Tom has made
 some additions:
 
   http://momjian.postgresql.org/cgi-bin/pgrelease
 
 I will probably go over them again in a few hours, update them to
 current CVS, then move them into our SGML documentation by Monday.

We talk about standby point-in-time-recovery (PITR) servers in the
release notes, but in the docs PITR has now been replaced by Continuous
Archiving and we talk about Warm Standby servers.

Can we call them Warm Standby servers? That makes more sense for the
general reader and matches the docs.


Also, not sure what the thoughts are regarding surnames. I'm referred to
as both Simon and Simon Riggs in the release notes. Should we have a
policy of first mention uses full name, subsequent mentions just use
first name if there is no confusion by doing so? 

-- 
  Simon Riggs 
  EnterpriseDB   http://www.enterprisedb.com


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Andreas Pflug]

Simon Riggs wrote:
 Zero administration overhead now possible (Alvaro)

   With autovacuum enabled, all required vacuuming will now take place
 without administrator intervention enabling wider distribution of
 embedded databases.
   
This was true for 8.1 already, no?

Regards,
Andreas


---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Joshua D. Drake]

Andreas Pflug wrote:

Simon Riggs wrote:

Zero administration overhead now possible (Alvaro)

With autovacuum enabled, all required vacuuming will now take place
without administrator intervention enabling wider distribution of
embedded databases.
  

This was true for 8.1 already, no?


No. 8.1 did not have it turned on by default.

Sincerely,

Joshua D. Drake




Regards,
Andreas


---(end of broadcast)---
TIP 6: explain analyze is your friend




--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Simon Riggs]

On Wed, 2006-09-20 at 18:22 +0200, Andreas Pflug wrote:
 Simon Riggs wrote:
  Zero administration overhead now possible (Alvaro)
 
  With autovacuum enabled, all required vacuuming will now take place
  without administrator intervention enabling wider distribution of
  embedded databases.

 This was true for 8.1 already, no?

Hmmm. You're correct.

Perhaps that is not a major change after all.

-- 
  Simon Riggs 
  EnterpriseDB   http://www.enterprisedb.com


---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Gregory Stark]

Joshua D. Drake [EMAIL PROTECTED] writes:

 No. 8.1 did not have it turned on by default.

Neither does 8.2 though.

-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Alvaro Herrera]

Simon Riggs wrote:
 On Wed, 2006-09-20 at 18:22 +0200, Andreas Pflug wrote:
  Simon Riggs wrote:
   Zero administration overhead now possible (Alvaro)
  
 With autovacuum enabled, all required vacuuming will now take place
   without administrator intervention enabling wider distribution of
   embedded databases.
 
  This was true for 8.1 already, no?
 
 Hmmm. You're correct.
 
 Perhaps that is not a major change after all.

What happened in 8.2 is that you no longer need database-wide vacuums,
ever (except for template databases).  Not sure if that qualifies as a
major change or not.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Joshua D. Drake]

Gregory Stark wrote:

Joshua D. Drake [EMAIL PROTECTED] writes:


No. 8.1 did not have it turned on by default.


Neither does 8.2 though.


oh... heh.

J







--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Release notes

[Jim C. Nasby]

On Wed, Sep 20, 2006 at 05:10:13PM +0100, Simon Riggs wrote:
 Also, not sure what the thoughts are regarding surnames. I'm referred to
 as both Simon and Simon Riggs in the release notes. Should we have a
 policy of first mention uses full name, subsequent mentions just use
 first name if there is no confusion by doing so? 

Hrm, I'd assumed that well known community members didn't get Surname
mentions... maybe we should just stick to First Last everywhere..
-- 
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Release notes

[Bruce Momjian]

Jim C. Nasby wrote:
 On Wed, Sep 20, 2006 at 05:10:13PM +0100, Simon Riggs wrote:
  Also, not sure what the thoughts are regarding surnames. I'm referred to
  as both Simon and Simon Riggs in the release notes. Should we have a
  policy of first mention uses full name, subsequent mentions just use
  first name if there is no confusion by doing so? 
 
 Hrm, I'd assumed that well known community members didn't get Surname
 mentions... maybe we should just stick to First Last everywhere..

My system has been to use first names if the person appears at the
bottom of the TODO list, else use full name in all references.  We refer
to too many people to use full names only on the first reference.


-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Release notes

[Alvaro Herrera]

Bruce Momjian wrote:
 Jim C. Nasby wrote:
  On Wed, Sep 20, 2006 at 05:10:13PM +0100, Simon Riggs wrote:
   Also, not sure what the thoughts are regarding surnames. I'm referred to
   as both Simon and Simon Riggs in the release notes. Should we have a
   policy of first mention uses full name, subsequent mentions just use
   first name if there is no confusion by doing so? 
  
  Hrm, I'd assumed that well known community members didn't get Surname
  mentions... maybe we should just stick to First Last everywhere..
 
 My system has been to use first names if the person appears at the
 bottom of the TODO list, else use full name in all references.  We refer
 to too many people to use full names only on the first reference.

The problem is that the release notes don't contain the bottom of the
TODO list.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Release notes

[Bruce Momjian]

Simon Riggs wrote:
 On Fri, 2006-09-15 at 15:37 -0400, Bruce Momjian wrote:
  I have completed my first pass over the release notes and Tom has made
  some additions:
  
  http://momjian.postgresql.org/cgi-bin/pgrelease
  
  I will probably go over them again in a few hours, update them to
  current CVS, then move them into our SGML documentation by Monday.
 
 We talk about standby point-in-time-recovery (PITR) servers in the
 release notes, but in the docs PITR has now been replaced by Continuous
 Archiving and we talk about Warm Standby servers.
 
 Can we call them Warm Standby servers? That makes more sense for the
 general reader and matches the docs.

Agreed. Updated.

 Also, not sure what the thoughts are regarding surnames. I'm referred to
 as both Simon and Simon Riggs in the release notes. Should we have a
 policy of first mention uses full name, subsequent mentions just use
 first name if there is no confusion by doing so? 

OK, changed to Simon, but am open to making more wholesale changes.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/release.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/release.sgml,v
retrieving revision 1.446
diff -c -c -r1.446 release.sgml
*** doc/src/sgml/release.sgml	20 Sep 2006 22:48:47 -	1.446
--- doc/src/sgml/release.sgml	21 Sep 2006 03:09:54 -
***
*** 37,52 
   
  para
   This release adds many improvements to commands and database
!  facilities that were requested by users.  Rather than adding a
!  few new features, this release makes many features from previous
!  releases easier to use.  For example, it is now much easier to
!  create standby point-in-time-recovery (PITR) servers.  Many
   performance bottlenecks have been eliminated, allowing more
!  functionality to be enabled by default.  Various additions will
!  make porting from other databases easier.  The changes in this
!  release continue the productnamePostgreSQL/ tradition of
!  being not only the most advanced open source database, but also
!  the easiest to use.
  /para
  
 /sect2
--- 37,52 
   
  para
   This release adds many improvements to commands and database
!  facilities that were requested by users.  Rather than adding
!  a few new features, this release makes many features from
!  previous releases easier to use.  For example, there are now
!  additional controls for continuous archiving.  Many
   performance bottlenecks have been eliminated, allowing more
!  functionality to be enabled by default.  Various additions
!  will make porting from other databases easier.  The changes
!  in this release continue the productnamePostgreSQL/
!  tradition of being not only the most advanced open source
!  database, but also the easiest to use.
  /para
  
 /sect2
***
*** 489,509 
  
listitem
 para
! Allow a forced switch to a new xlog file (Simon Riggs, Tom)
 /para
  
 para
! This is valuable for keeping acronymPITR/ standby
! servers in sync with the master.  xlog file switching also
! happens automatically during functionpg_stop_backup()/.
! This ensures that acronymPITR/ servers have all xlog
  files needed for recovery.
 /para
/listitem
  
listitem
 para
! Add acronymWAL/ informational functions (Simon Riggs)
 /para
  
 para
--- 489,509 
  
listitem
 para
! Allow a forced switch to a new xlog file (Simon, Tom)
 /para
  
 para
! This is valuable for keeping continuous archiving servers
! in sync with the master.  xlog file switching also happens
! automatically during functionpg_stop_backup()/.  This
! ensures that continuous archiving servers have all xlog
  files needed for recovery.
 /para
/listitem
  
listitem
 para
! Add acronymWAL/ informational functions (Simon)
 /para
  
 para
***
*** 517,543 
listitem
 para
  Allow acronymWAL/ replay to be restored quicker in case
! of a crash (Simon Riggs)
 /para
  
 para
  The server now does periodic checkpoints during acronymWAL/
  recovery, so if there is a crash, future acronymWAL/
  recovery is shortened.  This also eliminates the need for
! acronymPITR/ standby servers to replay the entire log
! since the base backup if they crash.
 /para
/listitem
  
listitem
 para
  Add varnamearchive_timeout/ to force xlog file switches
! at a given interval (Simon Riggs)
 /para
  
 

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Bruce Momjian]

Usually the major items just jump out of the release list.  In this
case, nothing really jumped out, and I felt if I listed sereral, it was
going to look weak because they were not big things, so I figured I
would just go with the broad list.

The criteria I usually use are things that were not easy to do before.

Does the list below look good for inclusion?

I guess my point is that what we have now overwhelms people with the
number of small things we did.  If you try to put a few at the top, does
it diminish it because the top things are not large?

Or perhaps we can do more broad-stroke list items, like monitoring or
performance, as listed below.

---

Simon Riggs wrote:
 I'd like to include a section on Major changes in this release at the
 top of the release notes, as has been done for at least the last 6 major
 releases. The notes below are one stab at that, for **discussion**. I've
 tried to arrange specific changes into groups... 
 
 
 Major changes in this release:
 
 Improved scalability and performance on multi-processor systems (Tom,
 Alvaro, Itagaki, Qingqing, Heikki)
 
   A variety of changes improves the performance of both sequential scans
 and index scans, as well as enhancing multi-processor scalability. The
 advanced query optimizer has also been further enhanced, allowing
 indexes and partitioning to be useful in more cases. 
 
 Improved utility and large query performance (Tom, Simon, Alon, Andreas)
 
   Large sorts will have typical performance increases of 100-300%,
 improving complex queries and creating new indexes. Loading times have
 also been reduced. Large queries, data loads, upgrades and restores will
 be considerably improved.
 
 Improved monitoring and performance tuning (Tom, Bruce, Greg, Larry)
 
   Overhead of statistics collection has been considerably reduced and new
 statistics and system information is available. Better query logging
 improves diagnostics and especially performance tuning. Server now
 includes DTrace support. Indexes can now also be created CONCURRENTLY,
 allowing application tuning without effecting server availability.
 
 Zero administration overhead now possible (Alvaro)
 
   With autovacuum enabled, all required vacuuming will now take place
 without administrator intervention enabling wider distribution of
 embedded databases.
 
 Improved defaults and configuration (Peter, Andrew)
 
   Installation defaults are now improved for many tunable memory
 parameters and these can now be specified in kB, MB and GB. 
 
 Warm Standby Servers for High Availability (Simon, Tom)
 
   Warm Standby servers can now be more easily configured and are
 appropriate in a wider range of circumstances than previously.
 
 Improved scalability and performance of text search: GIN and Tsearch2
 (Teodor, Oleg)
 
   New GIN indexes allow much larger text search indexes than were
 previously possible. TSearch2 has been enhanced and performance has also
 been greatly improved.
 
 Enhanced DML Functionality (Jonah, Joe, Tom, Susanne, Atsushi)
 
   INSERT/UPDATE/DELETE RETURNING and INSERT .. VALUES (), VALUES (),
 VALUES () allow more efficient application designs. Enhancements to
 UPDATE and DELETE allow additional constructs for clarity and ease of
 use.
 
 SQL:2003 Analytical functions (Sergey, Tom, Neil)
 
   All statistical aggregate functions defined by SQL:2003 are now
 supported and user-defined aggregates now can take multiple columns as
 inputs.
 
 -- 
   Simon Riggs 
   EnterpriseDB   http://www.enterprisedb.com
 
 
 ---(end of broadcast)---
 TIP 4: Have you searched our list archives?
 
http://archives.postgresql.org

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq

Re: [HACKERS] Release Notes: Major Changes in 8.2

[Josh Berkus]

Bruce,

What happened to PL/pgSQL debugging?  Did it die?

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match

Re: [HACKERS] Release notes

[Jim C. Nasby]

On Mon, Sep 18, 2006 at 06:47:02PM -0400, Bruce Momjian wrote:
  Both this and pg_prepared_statements are very useful for pooled
  connection setups.
  
  Should read Both of these are very useful...
 
 I don't think I can't change that because they are two separate bullet
 items.
 
Except it's refering to both items. Maybe the two items should just be
combined into one?
-- 
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Release notes

[Bruce Momjian]

Jim C. Nasby wrote:
 On Mon, Sep 18, 2006 at 06:47:02PM -0400, Bruce Momjian wrote:
   Both this and pg_prepared_statements are very useful for pooled
   connection setups.
   
   Should read Both of these are very useful...
  
  I don't think I can't change that because they are two separate bullet
  items.
  
 Except it's refering to both items. Maybe the two items should just be
 combined into one?

Please post some combined wording, but I am afraid it will be too
complicated to merge them.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Release notes

[Jim C. Nasby]

On Tue, Sep 19, 2006 at 09:37:39AM -0400, Bruce Momjian wrote:
 Jim C. Nasby wrote:
  On Mon, Sep 18, 2006 at 06:47:02PM -0400, Bruce Momjian wrote:
Both this and pg_prepared_statements are very useful for pooled
connection setups.

Should read Both of these are very useful...
   
   I don't think I can't change that because they are two separate bullet
   items.
   
  Except it's refering to both items. Maybe the two items should just be
  combined into one?
 
 Please post some combined wording, but I am afraid it will be too
 complicated to merge them.

- Add pg_prepared_statements and pg_cursors system views to show prepared
statements and open cursors.

Both of these are very useful for pooled connection setups.
-- 
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Release notes

[Bruce Momjian]

Jim C. Nasby wrote:
 On Tue, Sep 19, 2006 at 09:37:39AM -0400, Bruce Momjian wrote:
  Jim C. Nasby wrote:
   On Mon, Sep 18, 2006 at 06:47:02PM -0400, Bruce Momjian wrote:
 Both this and pg_prepared_statements are very useful for pooled
 connection setups.
 
 Should read Both of these are very useful...

I don't think I can't change that because they are two separate bullet
items.

   Except it's refering to both items. Maybe the two items should just be
   combined into one?
  
  Please post some combined wording, but I am afraid it will be too
  complicated to merge them.
 
 - Add pg_prepared_statements and pg_cursors system views to show prepared
 statements and open cursors.
 
 Both of these are very useful for pooled connection setups.

No, you are confusing two different pieces of functionality, just to get
a single description.  It is not worth it.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 6: explain analyze is your friend

Re: [HACKERS] Release notes

[Teodor Sigaev]

I see two entries:
* Improve subtransaction performance (Alvaro, Itagaki Takahiro, Tom)
* Improve sub-transaction performance (Itagaki Takahiro)
Aren't they the same?

Markup: New operators for array-subset comparisons (@, @, amp;amp;)



--
Teodor Sigaev   E-mail: [EMAIL PROTECTED]
   WWW: http://www.sigaev.ru/

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings

Re: [HACKERS] Release notes

[Bruce Momjian]

Teodor Sigaev wrote:
 I see two entries:
  * Improve subtransaction performance (Alvaro, Itagaki Takahiro, Tom)
  * Improve sub-transaction performance (Itagaki Takahiro)
 Aren't they the same?

Yes, removed.

 Markup: New operators for array-subset comparisons (@, @, amp;amp;)

Yes, that will be fixed in the move to SGML today.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org

Re: [HACKERS] Release notes

[Jim C. Nasby]

I couldn't remember if you wanted grammar/spelling nitpicks, so I
included them... sorry for the noise if you didn't want them.

#Improve performance of statistics monitoring, especially
pg_stat_activity (Tom)#

I would s/pg_stat_activity/stats_command_string/, since that's where the
actual change was. Can probably get combined with Default
stats_command_string to 'on' as well.

Add system view pg_prepared_statements to show prepared statements
(Joachim Wieland)
Add system view pg_cursors to show open cursors (Joachim Wieland)

Both this and pg_prepared_statements are very useful for pooled
connection setups.

Should read Both of these are very useful...

The old behavior is still available by omitting '.'. The new behavior is
substantially more useful since it allows, for example, triggers to
check for data changes with 'if row(new.) is distinct from row(old.*)'.

This isn't really clear... are you saying you can do if row(new*)? Also,
is the lack of * in the new example intentional?

Allow placeholder (shell) types to be create (Martijn van Oosterhout)

should be created...

Remove dead index entries during btree page split (Junji Teramoto)

Technically should be s/during/before/. Though, this is already listed
before under performance; not sure what the intention with duplicate
entries is... 

Avoid extra scan of table during VACUUM of index-less table (Greg
Stark)

Should be 'tables'.

Add option to allow indexes to be created indexes without blocking
concurrent writes to the table (Greg Stark)

Drop second 'indexes'.

Add option to run the entire session in a single transaction (Simon)

If this is doing what I think it is, it'd be clearer to say allow
turning autocommit off. We're not actually inforcing that the entire
session be a single transaction, right?

Rtree has been re implemented using GIST.

Missing -.
-- 
Jim Nasby[EMAIL PROTECTED]
EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

Re: [HACKERS] Release notes

[Bruce Momjian]

Jim C. Nasby wrote:
 I couldn't remember if you wanted grammar/spelling nitpicks, so I
 included them... sorry for the noise if you didn't want them.
 
 #Improve performance of statistics monitoring, especially
 pg_stat_activity (Tom)#
 
 I would s/pg_stat_activity/stats_command_string/, since that's where the
 actual change was. Can probably get combined with Default
 stats_command_string to 'on' as well.
 
 Add system view pg_prepared_statements to show prepared statements
 (Joachim Wieland)
 Add system view pg_cursors to show open cursors (Joachim Wieland)

Good.

 
 Both this and pg_prepared_statements are very useful for pooled
 connection setups.
 
 Should read Both of these are very useful...

I don't think I can't change that because they are two separate bullet
items.

 The old behavior is still available by omitting '.'. The new behavior is
 substantially more useful since it allows, for example, triggers to
 check for data changes with 'if row(new.) is distinct from row(old.*)'.
 
 This isn't really clear... are you saying you can do if row(new*)? Also,
 is the lack of * in the new example intentional?
 

Yea, it was confusing. Updated:

Yes, it was confusing.  I reordered it to be:

The new behavior is substantially more useful since it allows,
for example, triggers to check for data changes with literalIF
row(new.*) IS DISTINCT FROM row(old.*)/.  The old behavior is 
still available by omitting literal.*/.

I made all the other changes you listed below.  If anyone has other
improvements, please let me know.

---



 Allow placeholder (shell) types to be create (Martijn van Oosterhout)
 
 should be created...
 
 Remove dead index entries during btree page split (Junji Teramoto)
 
 Technically should be s/during/before/. Though, this is already listed
 before under performance; not sure what the intention with duplicate
 entries is... 

 
 Avoid extra scan of table during VACUUM of index-less table (Greg
 Stark)
 
 Should be 'tables'.
 
 Add option to allow indexes to be created indexes without blocking
 concurrent writes to the table (Greg Stark)
 
 Drop second 'indexes'.
 
 Add option to run the entire session in a single transaction (Simon)
 
 If this is doing what I think it is, it'd be clearer to say allow
 turning autocommit off. We're not actually inforcing that the entire
 session be a single transaction, right?
 
 Rtree has been re implemented using GIST.
 
 Missing -.
 -- 
 Jim Nasby[EMAIL PROTECTED]
 EnterpriseDB  http://enterprisedb.com  512.569.9461 (cell)
 
 ---(end of broadcast)---
 TIP 2: Don't 'kill -9' the postmaster

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly

Re: [HACKERS] Release notes

[Neil Conway]

Tom Lane wrote:

ISTR that we had patch-merging problems too, because any patch
submitters who took it seriously were trying to patch the same chunk
of release.sgml.


That could be annoying, yes. I'm not sure how serious a problem it would 
be in practice -- we could always adopt workarounds like allowing 
release note additions anywhere within a section, rather than only at 
the end. It might actually be better to cluster related changes within a 
given section of the release notes, anyway.



I tend to agree with Bruce that it's more efficient to go through the
CVS logs once than to try to do the work incrementally.


I think the amount of total work required is probably pretty similar, 
but incremental updates have several advantages. The work required is 
distributed among many people, which reduces the bus factor of the 
process. Incremental updates would also remove a significant task from 
the beta process, because most of the work would be done during the 
development cycle. As discussed earlier[1], I think the resulting 
release notes would also be more comprehensive and discuss issues in 
more depth, because they would be written while the details of the 
change are fresh in the developer's mind.



We should encourage people to write commit messages that are
sufficient for the release notes, but folding the text into
release.sgml immediately doesn't seem all that important.


Adding the text to release.sgml immediately would also make it more 
accessible to users, which I think would clearly be a Good Thing.


-Neil

[1] http://archives.postgresql.org/pgsql-hackers/2006-09/msg00615.php


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq

Re: [HACKERS] Release notes

[Neil Conway]

Bruce Momjian wrote:
Also, we are having trouble getting enough people to review/commit. 
Does adding an extra step discourage them even further?


I think if you are committing a patch, you should have a clear idea of 
what the patch does and what its broader impact on the system will be. 
Summarizing that information in a release note entry is not too much of 
an additional burden, I think: a committer *ought* to include some 
similar text in the CVS commit log message anyway.



How is maintaining another file on every commit going to go over?


Well, it would clearly not be on every commit: most commits don't 
warrant a mention in the release notes. If committers think that this 
burden is too much to bear, please speak up.


-Neil


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq