Draft release notes complete

On Wed, May 09, 2012 at 11:11:02PM -0400, Bruce Momjian wrote:

(Why is there no time zone shown in the date/time at the top?) I think
it will eventually show up here:

http://www.postgresql.org/docs/devel/static/release-9-2.html

The docs finally built 90 minutes after my commit, and the URL above is
now working. (Does it always take this long to update?)

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On 05/10/2012 06:33 AM, Bruce Momjian wrote:

On Wed, May 09, 2012 at 11:11:02PM -0400, Bruce Momjian wrote:

(Why is there no time zone shown in the date/time at the top?) I think
it will eventually show up here:

http://www.postgresql.org/docs/devel/static/release-9-2.html

The docs finally built 90 minutes after my commit, and the URL above is
now working. (Does it always take this long to update?)

the developer docs builds are a byproduct of the snaptshot generation
concept on borka.postgresql.org. For each snapshot we are doing a
complete buildfarm-run to verify the basic integrity of the current code
and only if that one succeeds we will generate a snapshot-tarball AND
upload the docs to the main website.
This whole process is not triggered by a commit but simply running on a
fixed "every 4 hours" cycle.

Stefan

On Thu, May 10, 2012 at 07:02:43AM +0200, Stefan Kaltenbrunner wrote:

On 05/10/2012 06:33 AM, Bruce Momjian wrote:

On Wed, May 09, 2012 at 11:11:02PM -0400, Bruce Momjian wrote:

(Why is there no time zone shown in the date/time at the top?) I think
it will eventually show up here:

http://www.postgresql.org/docs/devel/static/release-9-2.html

The docs finally built 90 minutes after my commit, and the URL above is
now working. (Does it always take this long to update?)

the developer docs builds are a byproduct of the snaptshot generation
concept on borka.postgresql.org. For each snapshot we are doing a
complete buildfarm-run to verify the basic integrity of the current code
and only if that one succeeds we will generate a snapshot-tarball AND
upload the docs to the main website.
This whole process is not triggered by a commit but simply running on a
fixed "every 4 hours" cycle.

OK, good to know. Sometimes I need a quick build that I can show
people, so I will just use my personal URL for those cases.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

On Thu, May 10, 2012 06:33, Bruce Momjian wrote:

On Wed, May 09, 2012 at 11:11:02PM -0400, Bruce Momjian wrote:

http://www.postgresql.org/docs/devel/static/release-9-2.html

To "E.1.2.5. Monitoring" should be added:

"Rename pg_stat_activity.current_query to query (Magnus Hagander)"

And perhaps (same paragraph):

"The previous query values are preserved, allowing for enhanced analysis."

would be clearer as:

"The last query values are preserved, allowing for enhanced analysis."

Erik Rijkers

Bruce Momjian <bruce@momjian.us> writes:

The docs finally built 90 minutes after my commit, and the URL above is
now working. (Does it always take this long to update?)

I believe the new implementation of that stuff is that the devel docs
are built whenever the buildfarm member guaibasaurus runs for HEAD,
which it seems to do on an hourly schedule. This is definitely not as
fast-responding as Peter's former custom script, but I'm not sure if
it's worth thinking of another way.

regards, tom lane

On Wed, May 9, 2012 at 11:11 PM, Bruce Momjian <bruce@momjian.us> wrote:

I have completed my draft of the 9.2 release notes, and committed it to
git.

Extra parens:
Remove the spclocation field from pg_tablespace (Magnus Hagander, Tom Lane))
Reduce overhead of creating virtual transaction id locks ((Robert
Haas, Jeff Davis)

The antecedent of "these" is unclear:
Allow backends to detect postmaster death via a pipe read failure,
rather than polling (Peter Geoghegan, Heikki Linnakangas)
These are internally called "latches".

Missing comma:
Cancel queries if clients get disconnected (Florian Pflug Greg Jaskiewicz)

You mean "effect":
Such casts have no affect.

I think all three of these are the same thing:
Avoid table and index rebuilds when NUMERIC, VARBIT, and temporal
columns are changed in compatible ways (Noah Misch)
Reduce need to rebuild indexes for various ALTER TABLE operations
(Noah Misch) DUPLICATE?
Avoid index rebuilds for no-rewrite ALTER TABLE / ALTER TYPE (Noah Misch)

This feature wasn't committed at all:
Parallel pg_dump (Robert Haas, Joachim Wieland) DETAILS?

Yes, this is still true:
This is currently unused. STILL TRUE?

As a general comment, I think that your new policy of crediting the
reviewer on every feature except when that reviewer is also a
committer has produced a horrific mess. Just to pick one of many
examples, consider this item:

Add a security_barrier option for views (KaiGai Kohei, Noah Misch)

Here is what the commit message says:

Patch by KaiGai Kohei; original problem report by Heikki Linnakangas
(in October 2009!). Review (in earlier versions) by Noah Misch and
others. Design advice by Tom Lane and myself. Further review and
cleanup by me.

So there are four people mentioned in this commit message, and you've
picked out two of them to credit, not on the basis of who did the most
work, but rather on the basis of which ones happen to not be
committers. The result is that, as I read through these release
notes, one gets what I believe to be a very misleading notion of who
developed which features. I don't object to not being credited on
this one, but I don't think it makes sense to credit Noah and NOT
credit me. As you have it, people who did little more than say "yep,
looks fine to me" are credited almost equally with the people who
wrote the code, while a committer who heavily revised the patch may
not be mentioned at all, or sometimes (seemingly at random) they are.

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

On 10.05.2012 06:11, Bruce Momjian wrote:

I have completed my draft of the 9.2 release notes, and committed it to
git.

Thanks! I committed a few trivial fixes, below are a few more I wasn't
sure about:

* Add support for range data types (Jeff Davis, Tom Lane, Alexander Korotkov)

The range data type records a lower and upper bound, and supports comparisons like contains, overlaps, and intersection.

/s/comparisons/operations/ ?

* Allow a user to cancel queries in other owned sessions using pg_cancel_backend() (Magnus Hagander)

Previously only the superuser could cancel queries.

"other owned sessions" is a bit ambiguous. It reads to me like
"possessed sessions" or "0wned sessions". It's not clear it means
sessions owned by the same user. How about "... to cancel queries in his
other sessions, using ..." ? Or:

* Allow a non-superuser to cancel queries in another backend using
pg_cancel_backend(), as long as the victim backend belongs to the same user

Previously only the superuser could cancel queries.

* Change default names of triggers to fire action triggers before check triggers (Tom Lane)

This allows default-named check triggers to check post-action rows.

That's quite a mouthful :-). I don't understand what it means.

In psql tab completion, complete SQL key words based on COMP_KEYWORD_CASE setting and the perhaps case of the partially-supplied word (Peter Eisentraut, Fujii Masao)

Which is correct spelling, "keyword" or "key word"? We seem to use both
in the docs. "Keyword" sounds much better to me, but I think I might be
more prone to write words together than native English speakers.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On Thu, May 10, 2012 at 5:11 AM, Bruce Momjian <bruce@momjian.us> wrote:

(Why is there no time zone shown in the date/time at the top?)   I think
it will eventually show up here:

       http://www.postgresql.org/docs/devel/static/release-9-2.html

Other than the comments others have specified:

* Add libpq parameters for specifying the locations of server-side SSL
files (Peter Eisentraut)

Those are regular server side gucs and not libpq parameters. You
certainly can't control the location of server-side files with libpq
parameters..

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On 10 May 2012 04:11, Bruce Momjian <bruce@momjian.us> wrote:

I have completed my draft of the 9.2 release notes, and committed it to
git.  I am waiting for our development docs to build, but after 40
minutes, I am still waiting:

       http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=guaibasaurus&amp;dt=latest&amp;stg=make-doc

(Why is there no time zone shown in the date/time at the top?)   I think
it will eventually show up here:

       http://www.postgresql.org/docs/devel/static/release-9-2.html

My private build is now online:

       http://momjian.us/tmp/pgsql/release-9-2.html

I tested creation of the HISTORY file so Tom shouldn't need to fix
missing markup tomorrow.  :-)

Couple typo corrections attached.

--
Thom

On 05/10/2012 01:29 AM, Tom Lane wrote:

Bruce Momjian<bruce@momjian.us> writes:

The docs finally built 90 minutes after my commit, and the URL above is
now working. (Does it always take this long to update?)

I believe the new implementation of that stuff is that the devel docs
are built whenever the buildfarm member guaibasaurus runs for HEAD,
which it seems to do on an hourly schedule. This is definitely not as
fast-responding as Peter's former custom script, but I'm not sure if
it's worth thinking of another way.

I don't see any reason it can't run more frequently, though. Currently a
run takes 15 minutes or so. We could reduce that by making it skip some
steps, and get it down to about 10 minutes. It would be perfectly
reasonable to run every 5 minutes (it won't schedule concurrent runs -
if the lock file is held by another run it exits gracefully). Of course,
that's up to Magnus and Stefan.

cheers

andrew

On Thu, May 10, 2012 at 12:43 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

On 05/10/2012 01:29 AM, Tom Lane wrote:

Bruce Momjian<bruce@momjian.us>  writes:

The docs finally built 90 minutes after my commit, and the URL above is
now working.  (Does it always take this long to update?)

I believe the new implementation of that stuff is that the devel docs
are built whenever the buildfarm member guaibasaurus runs for HEAD,
which it seems to do on an hourly schedule.  This is definitely not as
fast-responding as Peter's former custom script, but I'm not sure if
it's worth thinking of another way.

I don't see any reason it can't run more frequently, though. Currently a run
takes 15 minutes or so. We could reduce that by making it skip some steps,
and get it down to about 10 minutes. It would be perfectly reasonable to run
every 5 minutes (it won't schedule concurrent runs - if the lock file is
held by another run it exits gracefully). Of course, that's up to Magnus and
Stefan.

If we can make it do *just* the docs, we can certainly run it a bit
more often. But we don't want to make it run the full set of checks
more or less continously, since the machine is shared with a number of
other tasks...

I don't think 5 minutes is anywhere near necessary even for the docs,
but there is a lot of room between 5 minutes and 4 hours, so we can
definitely shorten it.

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

On 05/10/2012 06:49 AM, Magnus Hagander wrote:

On Thu, May 10, 2012 at 12:43 PM, Andrew Dunstan<andrew@dunslane.net> wrote:

On 05/10/2012 01:29 AM, Tom Lane wrote:

Bruce Momjian<bruce@momjian.us> writes:

The docs finally built 90 minutes after my commit, and the URL above is
now working. (Does it always take this long to update?)

I believe the new implementation of that stuff is that the devel docs
are built whenever the buildfarm member guaibasaurus runs for HEAD,
which it seems to do on an hourly schedule. This is definitely not as
fast-responding as Peter's former custom script, but I'm not sure if
it's worth thinking of another way.

I don't see any reason it can't run more frequently, though. Currently a run
takes 15 minutes or so. We could reduce that by making it skip some steps,
and get it down to about 10 minutes. It would be perfectly reasonable to run
every 5 minutes (it won't schedule concurrent runs - if the lock file is
held by another run it exits gracefully). Of course, that's up to Magnus and
Stefan.

If we can make it do *just* the docs, we can certainly run it a bit
more often. But we don't want to make it run the full set of checks
more or less continously, since the machine is shared with a number of
other tasks...

I don't think 5 minutes is anywhere near necessary even for the docs,
but there is a lot of room between 5 minutes and 4 hours, so we can
definitely shorten it.

If you only want a docs build then a buildfarm animal is probably not a
good choice. Do you want to divorce that from building validated snapshots?

BTW, if there has been no change a buildfarm animal normally does no
work (other than a git pull followed by the check for updates), which is
why it's often safe to schedule it very frequently. However, if you need
to schedule tasks at times when it's known not to be running then a
sparse schedule makes sense.

cheers

andrew

On 05/09/2012 11:11 PM, Bruce Momjian wrote:

I have completed my draft of the 9.2 release notes, and committed it to
git. I am waiting for our development docs to build, but after 40
minutes, I am still waiting:

http://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=guaibasaurus&amp;dt=latest&amp;stg=make-doc

(Why is there no time zone shown in the date/time at the top?) I think
it will eventually show up here:

http://www.postgresql.org/docs/devel/static/release-9-2.html

My private build is now online:

http://momjian.us/tmp/pgsql/release-9-2.html

I tested creation of the HISTORY file so Tom shouldn't need to fix
missing markup tomorrow. :-)

This has broken my docs build because of this line:

release-9.2.sgml:1946: Urba&#324;nski, Steve Singer)

with this error:

openjade:/home/bf/bfr/root/HEAD/pgsql.9367/../pgsql/doc/src/sgml/release-9.2.sgml:1946:14:E: "324" is not a character number in the document character set

cheers

andrew

On 10 May 2012 04:11, Bruce Momjian <bruce@momjian.us> wrote:

I have completed my draft of the 9.2 release notes, and committed it to
git.  I am waiting for our development docs to build, but after 40
minutes, I am still waiting:

"Allow the bgwriter, walwriter, and statistics collector to sleep more
efficiently during periods of inactivity (Peter Geoghegan, Heikki
Linnakangas, Tom Lane)...This reduces CPU wake-ups."

I think that there should be mention of why this is a good thing. When
fully idle the server reaches less than a single wake-up per second,
which I think is a nice, relevant fact. You should add the archiver
and checkpointer to that list, though I suppose you could argue that
the checkpointer, as a "new" auxiliary process, shouldn't count.

I'm not really sure why you've listed Daniel Farina as a co-author of
the pg_stat_statements normalisation feature. He did a good job of
reviewing it, but he didn't actually contribute any code.

Why can't we call group commit group commit (and for that matter,
index-only scans index-only scans), so that people will understand
that we are now competitive with other RDBMSs in this area? "Improve
performance of WAL writes when multiple transactions commit at the
same time" seems like a pretty bad description, since it doesn't make
any reference to batching of commits. Also, I don't think that the
placement of this as the second to last performance feature is
commensurate with its actual importance. Still, the actual major
feature list is a much more relevant indicator of how it is felt that
individual features should be weighed, and of course that hasn't been
decided upon yet.

"Change pg_stat_statements' total_time column to be measured in
milliseconds (Tom Lane)". Surely this should be under
"pg_stat_statements"?

Does "Make the visibility map crash-safe" really belong under "Performance"?

It's not clear that this isn't just within comments that will be later
removed, but I'd remove all references to "we".

--
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services

On 05/10/2012 08:11 AM, Peter Geoghegan wrote:

I'm not really sure why you've listed Daniel Farina as a co-author of
the pg_stat_statements normalisation feature. He did a good job of
reviewing it, but he didn't actually contribute any code.

It looks like reviewers have been given credit throughout.

cheers

andrew

On 10 May 2012 13:11, Peter Geoghegan <peter@2ndquadrant.com> wrote:

Why can't we call group commit group commit (and for that matter,
index-only scans index-only scans), so that people will understand
that we are now competitive with other RDBMSs in this area? "Improve
performance of WAL writes when multiple transactions commit at the
same time" seems like a pretty bad description, since it doesn't make
any reference to batching of commits.  Also, I don't think that the
placement of this as the second to last performance feature is
commensurate with its actual importance.

Agreed.

Group Commit is a recognised term and also one where other DBMS, e.g.
Marea have included that feature recently.

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

On Thu, May 10, 2012 at 2:24 PM, Andrew Dunstan <andrew@dunslane.net> wrote:

On 05/10/2012 08:11 AM, Peter Geoghegan wrote:

I'm not really sure why you've listed Daniel Farina as a co-author of the
pg_stat_statements normalisation feature. He did a good job of reviewing
it, but he didn't actually contribute any code.

It looks like reviewers have been given credit throughout.

Which could be good incentive to become more involved in reviewing for some
people.

On 10.05.2012 13:21, Thom Brown wrote:

On 10 May 2012 04:11, Bruce Momjian<bruce@momjian.us> wrote:

I have completed my draft of the 9.2 release notes, and committed it to
git.

...

Couple typo corrections attached.

Applied.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

On 05/10/2012 08:28 AM, Vik Reykja wrote:

On Thu, May 10, 2012 at 2:24 PM, Andrew Dunstan <andrew@dunslane.net
<mailto:andrew@dunslane.net>> wrote:

On 05/10/2012 08:11 AM, Peter Geoghegan wrote:

I'm not really sure why you've listed Daniel Farina as a
co-author of the pg_stat_statements normalisation feature. He
did a good job of reviewing it, but he didn't actually
contribute any code.

It looks like reviewers have been given credit throughout.

Which could be good incentive to become more involved in reviewing for
some people.

Right, but I think it would be good to identify them explicitly as
reviewers if we're going to include the names. Otherwise it could enable
people to claim authorship of something they did not in fact author, and
even without that would dilute the claim to authorship of the actual
author(s).

cheers

andrew