subject:"Re\: \[HACKERS\] Draft release notes complete"



On 09/05/2012 06:13 PM, Peter Eisentraut wrote:

On 8/29/12 11:52 PM, Andrew Dunstan wrote:

Why does this need to be tied into the build farm?  Someone can surely

set up a script that just runs the docs build at every check-in, like it
used to work.  What's being proposed now just sounds like a lot of
complication for little or no actual gain -- net loss in fact.

It doesn't just build the docs. It makes the dist snapshots too.

Thus making the turnaround time on a docs build even slower ... ?



A complete run of this process takes less than 15 minutes. And as I have 
pointed out elsewhere that could be reduced substantially by skipping 
certain steps. It's as simple as changing the command line in the 
crontab entry.


The only reason there is a significant delay is that the administrators 
have chosen not to run the process more than once every 4 hours. That's 
a choice not dictated by the process they are using, but by other 
considerations concerning the machine it's being run on. Since I am not 
one of the admins and don't really want to take responsibility for it I 
am not going to second guess them. On the very rare occasions when I 
absolutely have to have the totally up to date docs I build them myself 
- it takes about 60 seconds on my modest hardware.



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

2012-09-05 Thread Tom Lane

Andrew Dunstan and...@dunslane.net writes:
 The only reason there is a significant delay is that the administrators 
 have chosen not to run the process more than once every 4 hours. That's 
 a choice not dictated by the process they are using, but by other 
 considerations concerning the machine it's being run on. Since I am not 
 one of the admins and don't really want to take responsibility for it I 
 am not going to second guess them. On the very rare occasions when I 
 absolutely have to have the totally up to date docs I build them myself 
 - it takes about 60 seconds on my modest hardware.

I think the argument for having a quick docs build service is not about
the time needed, but the need to have all the appropriate tools
installed.  While I can understand that argument for J Random Hacker,
I'm mystified why Bruce doesn't seem to have bothered to get a working
SGML toolset installed.  It's not like editing the docs is a one-shot
task for him.

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

2012-09-05 Thread Alvaro Herrera

Excerpts from Tom Lane's message of mié sep 05 20:24:08 -0300 2012:
 Andrew Dunstan and...@dunslane.net writes:
  The only reason there is a significant delay is that the administrators 
  have chosen not to run the process more than once every 4 hours. That's 
  a choice not dictated by the process they are using, but by other 
  considerations concerning the machine it's being run on. Since I am not 
  one of the admins and don't really want to take responsibility for it I 
  am not going to second guess them. On the very rare occasions when I 
  absolutely have to have the totally up to date docs I build them myself 
  - it takes about 60 seconds on my modest hardware.
 
 I think the argument for having a quick docs build service is not about
 the time needed, but the need to have all the appropriate tools
 installed.  While I can understand that argument for J Random Hacker,
 I'm mystified why Bruce doesn't seem to have bothered to get a working
 SGML toolset installed.  It's not like editing the docs is a one-shot
 task for him.

As far as I understand, Bruce's concern is not about seeing the docs
built himself, but having an HTML copy published somewhere that he can
point people to, after applying some patch.  To me, that's a perfectly
legitimate reason to want to have them quickly.

-- 
Álvaro Herrerahttp://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] Draft release notes complete

On Wed, Sep  5, 2012 at 09:56:32PM -0300, Alvaro Herrera wrote:
 Excerpts from Tom Lane's message of mié sep 05 20:24:08 -0300 2012:
  Andrew Dunstan and...@dunslane.net writes:
   The only reason there is a significant delay is that the administrators 
   have chosen not to run the process more than once every 4 hours. That's 
   a choice not dictated by the process they are using, but by other 
   considerations concerning the machine it's being run on. Since I am not 
   one of the admins and don't really want to take responsibility for it I 
   am not going to second guess them. On the very rare occasions when I 
   absolutely have to have the totally up to date docs I build them myself 
   - it takes about 60 seconds on my modest hardware.
  
  I think the argument for having a quick docs build service is not about
  the time needed, but the need to have all the appropriate tools
  installed.  While I can understand that argument for J Random Hacker,
  I'm mystified why Bruce doesn't seem to have bothered to get a working
  SGML toolset installed.  It's not like editing the docs is a one-shot
  task for him.
 
 As far as I understand, Bruce's concern is not about seeing the docs
 built himself, but having an HTML copy published somewhere that he can
 point people to, after applying some patch.  To me, that's a perfectly
 legitimate reason to want to have them quickly.

Correct.  I have always had a working SGML toolset.  If we are not going
to have the developer site run more often, I will just go back to
setting up my own public doc build, like I used to do.  I removed mine
when the official one was more current/reliable --- if that has changed,
I will return to my old setup, and publish my own URL for users to
verify doc changes.

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

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


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

2012-09-05 Thread Josh Berkus


 Correct.  I have always had a working SGML toolset.  If we are not going
 to have the developer site run more often, I will just go back to
 setting up my own public doc build, like I used to do.  I removed mine
 when the official one was more current/reliable --- if that has changed,
 I will return to my old setup, and publish my own URL for users to
 verify doc changes.

I guess I don't see why building every 4 hours is an issue?  That's 6
times/day.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.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] Draft release notes complete



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

On Wed, Sep  5, 2012 at 09:56:32PM -0300, Alvaro Herrera wrote:

Excerpts from Tom Lane's message of mié sep 05 20:24:08 -0300 2012:

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

The only reason there is a significant delay is that the administrators
have chosen not to run the process more than once every 4 hours. That's
a choice not dictated by the process they are using, but by other
considerations concerning the machine it's being run on. Since I am not
one of the admins and don't really want to take responsibility for it I
am not going to second guess them. On the very rare occasions when I
absolutely have to have the totally up to date docs I build them myself
- it takes about 60 seconds on my modest hardware.

I think the argument for having a quick docs build service is not about
the time needed, but the need to have all the appropriate tools
installed.  While I can understand that argument for J Random Hacker,
I'm mystified why Bruce doesn't seem to have bothered to get a working
SGML toolset installed.  It's not like editing the docs is a one-shot
task for him.

As far as I understand, Bruce's concern is not about seeing the docs
built himself, but having an HTML copy published somewhere that he can
point people to, after applying some patch.  To me, that's a perfectly
legitimate reason to want to have them quickly.

Correct.  I have always had a working SGML toolset.  If we are not going
to have the developer site run more often, I will just go back to
setting up my own public doc build, like I used to do.  I removed mine
when the official one was more current/reliable --- if that has changed,
I will return to my old setup, and publish my own URL for users to
verify doc changes.


How often do you want? After all, 
http://developer.postgresql.org/docs/postgres/index.html is presumably 
going to keep pointing to where it now points.


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

On Wed, Sep  5, 2012 at 06:32:48PM -0700, Josh Berkus wrote:
 
  Correct.  I have always had a working SGML toolset.  If we are not going
  to have the developer site run more often, I will just go back to
  setting up my own public doc build, like I used to do.  I removed mine
  when the official one was more current/reliable --- if that has changed,
  I will return to my old setup, and publish my own URL for users to
  verify doc changes.
 
 I guess I don't see why building every 4 hours is an issue?  That's 6
 times/day.

I can't commit and send someone a URL showing the change because they
might actually read their email in less than 4 hours.

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

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


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

On Wed, Sep  5, 2012 at 09:33:35PM -0400, Andrew Dunstan wrote:
 
 On 09/05/2012 09:25 PM, Bruce Momjian wrote:
 On Wed, Sep  5, 2012 at 09:56:32PM -0300, Alvaro Herrera wrote:
 Excerpts from Tom Lane's message of mié sep 05 20:24:08 -0300 2012:
 Andrew Dunstan and...@dunslane.net writes:
 The only reason there is a significant delay is that the administrators
 have chosen not to run the process more than once every 4 hours. That's
 a choice not dictated by the process they are using, but by other
 considerations concerning the machine it's being run on. Since I am not
 one of the admins and don't really want to take responsibility for it I
 am not going to second guess them. On the very rare occasions when I
 absolutely have to have the totally up to date docs I build them myself
 - it takes about 60 seconds on my modest hardware.
 I think the argument for having a quick docs build service is not about
 the time needed, but the need to have all the appropriate tools
 installed.  While I can understand that argument for J Random Hacker,
 I'm mystified why Bruce doesn't seem to have bothered to get a working
 SGML toolset installed.  It's not like editing the docs is a one-shot
 task for him.
 As far as I understand, Bruce's concern is not about seeing the docs
 built himself, but having an HTML copy published somewhere that he can
 point people to, after applying some patch.  To me, that's a perfectly
 legitimate reason to want to have them quickly.
 Correct.  I have always had a working SGML toolset.  If we are not going
 to have the developer site run more often, I will just go back to
 setting up my own public doc build, like I used to do.  I removed mine
 when the official one was more current/reliable --- if that has changed,
 I will return to my old setup, and publish my own URL for users to
 verify doc changes.
 
 How often do you want? After all,
 http://developer.postgresql.org/docs/postgres/index.html is
 presumably going to keep pointing to where it now points.

Well, the old code checked every five minutes, and it rebuilt in 4
minutes, so there was a max of 10 minutes delay.

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

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


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

2012-09-05 Thread Stephen Frost

* Bruce Momjian (br...@momjian.us) wrote:
  How often do you want? After all,
  http://developer.postgresql.org/docs/postgres/index.html is
  presumably going to keep pointing to where it now points.
 
 Well, the old code checked every five minutes, and it rebuilt in 4
 minutes, so there was a max of 10 minutes delay.

I'm a bit mystified why we build them far *more* often than necessary..
Do we really commit documentation updates more than 6 times per day?
Wouldn't it be reasonably straight-forward to set up a commit-hook that
either kicks off a build itself, drops a file marker some place to
signal a cron job to do it, or something similar?

Have to agree with Bruce on this one, for my part.  I wonder if the
change to delay the crons was due to lack of proper locking or
tracking, or perhaps a lack of a filter for just changes which would
impact the documentation..

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] Draft release notes complete

On Wed, Sep  5, 2012 at 09:59:50PM -0400, Stephen Frost wrote:
 * Bruce Momjian (br...@momjian.us) wrote:
   How often do you want? After all,
   http://developer.postgresql.org/docs/postgres/index.html is
   presumably going to keep pointing to where it now points.
  
  Well, the old code checked every five minutes, and it rebuilt in 4
  minutes, so there was a max of 10 minutes delay.
 
 I'm a bit mystified why we build them far *more* often than necessary..
 Do we really commit documentation updates more than 6 times per day?
 Wouldn't it be reasonably straight-forward to set up a commit-hook that
 either kicks off a build itself, drops a file marker some place to
 signal a cron job to do it, or something similar?
 
 Have to agree with Bruce on this one, for my part.  I wonder if the
 change to delay the crons was due to lack of proper locking or
 tracking, or perhaps a lack of a filter for just changes which would
 impact the documentation..

What the script I donated did was to do a cvs update in the sgml
directory and look for changes --- if it found them, it rebuilt.


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

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


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



On 09/05/2012 09:59 PM, Stephen Frost wrote:

* Bruce Momjian (br...@momjian.us) wrote:

How often do you want? After all,
http://developer.postgresql.org/docs/postgres/index.html is
presumably going to keep pointing to where it now points.

Well, the old code checked every five minutes, and it rebuilt in 4
minutes, so there was a max of 10 minutes delay.

I'm a bit mystified why we build them far *more* often than necessary..
Do we really commit documentation updates more than 6 times per day?
Wouldn't it be reasonably straight-forward to set up a commit-hook that
either kicks off a build itself, drops a file marker some place to
signal a cron job to do it, or something similar?

Have to agree with Bruce on this one, for my part.  I wonder if the
change to delay the crons was due to lack of proper locking or
tracking, or perhaps a lack of a filter for just changes which would
impact the documentation..





The buildfarm code does not run if there are no changes. The job runs, 
sees that there are no changes, and exits.


And it has no problewm with collisions either. The code is guaranteed 
self-exclusionary. You can run it every minute from cron if you like and 
you will not get a collision. If it finds a running instance of itself 
it exits. Some people run the buildfarm script from cron every 15 
minutes or so relying on the locking mechanism.


And building the docs doesn't have a very high impact. And it takes 
about 2 minutes.


So, many of the assumptions / speculations in your email are wrong ;-)

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

2012-09-05 Thread Stephen Frost

* Andrew Dunstan (and...@dunslane.net) wrote:
 The buildfarm code does not run if there are no changes. The job
 runs, sees that there are no changes, and exits.

Right, hence it makes great sense to use it for this (as opposed to
Bruce's previous script or some other new one).  While it might appear
to be overkill, it actually does lots of useful and good things and
integrates better with the existing setup anyway.

Now that you've provided the magic sauce wrt --skip-steps, can we get an
admin to implement a doc-only build that runs more frequently to update
the dev docs..?

Andrew, if we're going to rely on that, even just internally, perhaps we
should go ahead and add documentation for it?

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] Draft release notes complete



On 09/05/2012 11:01 PM, Stephen Frost wrote:

* Andrew Dunstan (and...@dunslane.net) wrote:

The buildfarm code does not run if there are no changes. The job
runs, sees that there are no changes, and exits.

Right, hence it makes great sense to use it for this (as opposed to
Bruce's previous script or some other new one).  While it might appear
to be overkill, it actually does lots of useful and good things and
integrates better with the existing setup anyway.

Now that you've provided the magic sauce wrt --skip-steps, can we get an
admin to implement a doc-only build that runs more frequently to update
the dev docs..?

Andrew, if we're going to rely on that, even just internally, perhaps we
should go ahead and add documentation for it?





You mean in my copious spare time?

AIUI the only thing stopping the admins from doing what is wanted is a 
shortage of tuits. I suspect if we're all a tiny bit patient it will happen.


But I guess they can speak for themselves.

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

2012-09-05 Thread Stephen Frost

* Andrew Dunstan (and...@dunslane.net) wrote:
 You mean in my copious spare time?

If you're alright with the concept, then anyone can do it.  I was
looking more for your concurrence on the idea of documenting this
explicitly (which also implies that it'll be supported, etc).

I'd be happy to develop the actual patch to add the documentation.

 AIUI the only thing stopping the admins from doing what is wanted is
 a shortage of tuits. I suspect if we're all a tiny bit patient it
 will happen.

I agree that they'll now get to it, based off your explanation of how to
use --skip-steps, and it'll be done and good.

Thanks,

Stephen


signature.asc
Description: Digital signature

Re: [HACKERS] Draft release notes complete



On 09/05/2012 11:44 PM, Stephen Frost wrote:

* Andrew Dunstan (and...@dunslane.net) wrote:

You mean in my copious spare time?

If you're alright with the concept, then anyone can do it.  I was
looking more for your concurrence on the idea of documenting this
explicitly (which also implies that it'll be supported, etc).

I'd be happy to develop the actual patch to add the documentation.





Sure, go for it. The buildfarm code is entirely public, 
https://github.com/PGBuildFarm/client-code and the documentation lives 
on the wiki: 
http://wiki.postgresql.org/wiki/PostgreSQL_Buildfarm_Howto and an be 
edited by anyone with edit privs there.


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

2012-08-30 Thread Magnus Hagander

On Thu, Aug 30, 2012 at 5:20 AM, Peter Eisentraut pete...@gmx.net wrote:
 On Wed, 2012-08-29 at 22:23 -0400, Alvaro Herrera wrote:
Where are we on building the development docs more frequently?
  
   Still waiting for details on how it works to set that up on the
   buildfarm client.
 
  Where are we on this?

 Waiting on Andrew.

 As far as I can see, we need to update the machine to release 4.7, and
 then install a skip file or something like that.  Andrew, can you
 please explain how is that to be used?  I don't see it documented
 anywhere.

 Why does this need to be tied into the build farm?  Someone can surely
 set up a script that just runs the docs build at every check-in, like it
 used to work.  What's being proposed now just sounds like a lot of
 complication for little or no actual gain -- net loss in fact.

It doesn't have to. The gain is that we don't then end up conflicting
with the buildfarm on when we run. Unlike the old server, we try to
avoid running too many concurrent builds because it might kill other
services on the same box - which happened quite frequently on the old
one. In fact, it happened so frequently on the old one that people
stopped caring...

We also get the buildfarms functionality for collecting logs and
reporting them. Just some more we don't have to build a new set of
scripts for.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.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] Draft release notes complete

2012-08-29 Thread Bruce Momjian

On Thu, May 31, 2012 at 05:58:58PM +0200, Magnus Hagander wrote:
 On Thu, May 31, 2012 at 5:55 PM, Bruce Momjian br...@momjian.us wrote:
  On Tue, May 15, 2012 at 12:57:37PM -0400, Magnus Hagander wrote:
  On Fri, May 11, 2012 at 11:44 AM, Andrew Dunstan and...@dunslane.net 
  wrote:
  
  
   On 05/11/2012 05:32 AM, Magnus Hagander wrote:
  
  
   But in the interest of actually being productive - what *is* the
   usecase for needing a 5 minute turnaround time? I don't buy the check
   what a patch looks like, because that should be done *before* the
   commit, not after - so it's best verified by a local docs build anyway
   (which will also be faster).
  
   I'm sure we can put something in with a pretty quick turnaround again
   without too much strain on the system, but it does, as I mentioned
   before, require decoupling it from the buildfarm which means it's not
   just tweaking a config file.
  
  
   If it's of any use to you I have made some adjustments to the buildfarm 
   code
   which would let you do *just* the docs build (and dist make if you 
   want). It
   would still pull from git, and only do anything if there's a (relevant)
   change. So using that to set up a machine that would run every few 
   minutes
   might work. Of course, building the docs can itself be fairly compute
   intensive, so you still might not want to run every few minutes if 
   that's a
   limiting factor.
 
  that would definitely be useful. Compute intensive is not really a
  problem, we can easily shape the box on that (and I think we already
  do).
 
  Do you have some details of what to do and how to do it to use that,
  so Stefan can set it up for us ? ;)
 
  Where are we on building the development docs more frequently?
 
 Still waiting for details on how it works to set that up on the
 buildfarm client.

Where are we on this?

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

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


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

2012-08-29 Thread Alvaro Herrera

Excerpts from Bruce Momjian's message of mié ago 29 21:25:11 -0400 2012:
 On Thu, May 31, 2012 at 05:58:58PM +0200, Magnus Hagander wrote:
  On Thu, May 31, 2012 at 5:55 PM, Bruce Momjian br...@momjian.us wrote:
   On Tue, May 15, 2012 at 12:57:37PM -0400, Magnus Hagander wrote:
   On Fri, May 11, 2012 at 11:44 AM, Andrew Dunstan and...@dunslane.net 
   wrote:

If it's of any use to you I have made some adjustments to the 
buildfarm code
which would let you do *just* the docs build (and dist make if you 
want). It
would still pull from git, and only do anything if there's a (relevant)
change. So using that to set up a machine that would run every few 
minutes
might work. Of course, building the docs can itself be fairly compute
intensive, so you still might not want to run every few minutes if 
that's a
limiting factor.
  
   that would definitely be useful. Compute intensive is not really a
   problem, we can easily shape the box on that (and I think we already
   do).
  
   Do you have some details of what to do and how to do it to use that,
   so Stefan can set it up for us ? ;)
  
   Where are we on building the development docs more frequently?
  
  Still waiting for details on how it works to set that up on the
  buildfarm client.
 
 Where are we on this?

Waiting on Andrew.

As far as I can see, we need to update the machine to release 4.7, and
then install a skip file or something like that.  Andrew, can you
please explain how is that to be used?  I don't see it documented
anywhere.

Please note that we have cron jobs that run every branch (we use
run_build.pl for each branch separately, not run_branches.pl) and a
signle build-farm.conf.  It would be good if we could continue to use a
single config file for all builds, including a build that *only* does
the docs.  If we can have a second file that only #includes the other
one somehow and just tweaks %skip_step, that would work.

-- 
Álvaro Herrerahttp://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] Draft release notes complete

2012-08-29 Thread Peter Eisentraut

On Wed, 2012-08-29 at 22:23 -0400, Alvaro Herrera wrote:
Where are we on building the development docs more frequently?
   
   Still waiting for details on how it works to set that up on the
   buildfarm client.
  
  Where are we on this?
 
 Waiting on Andrew.
 
 As far as I can see, we need to update the machine to release 4.7, and
 then install a skip file or something like that.  Andrew, can you
 please explain how is that to be used?  I don't see it documented
 anywhere.

Why does this need to be tied into the build farm?  Someone can surely
set up a script that just runs the docs build at every check-in, like it
used to work.  What's being proposed now just sounds like a lot of
complication for little or no actual gain -- net loss in fact.




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

2012-08-29 Thread Andrew Dunstan



On 08/29/2012 11:20 PM, Peter Eisentraut wrote:

On Wed, 2012-08-29 at 22:23 -0400, Alvaro Herrera wrote:

Where are we on building the development docs more frequently?

Still waiting for details on how it works to set that up on the
buildfarm client.

Where are we on this?

Waiting on Andrew.

As far as I can see, we need to update the machine to release 4.7, and
then install a skip file or something like that.  Andrew, can you
please explain how is that to be used?  I don't see it documented
anywhere.

Why does this need to be tied into the build farm?  Someone can surely
set up a script that just runs the docs build at every check-in, like it
used to work.  What's being proposed now just sounds like a lot of
complication for little or no actual gain -- net loss in fact.




It doesn't just build the docs. It makes the dist snapshots too. And the 
old script often broke badly, IIRC. The current setup doesn't install 
anything if the build fails, which is a distinct improvement. And you 
can see the causes of any failure via the buildfarm logs.


But I don't really have any stake in this, I just created a tiny Module 
to help Magnus do what he wanted.


In answer to Alvaro's question, you can disable most steps via a command 
line switch --skip-steps, the value of which is a space separated list 
of names. I haven't documented it mainly because it was really developed 
for use in development. The allowed values are:


   install
   make
   make-doc
   install
   make-contrib
   install
   install-check
   contrib-install-check
   pl-install-check
   isolation-check
   check
   ecpg-check



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

2012-05-31 Thread Bruce Momjian

On Tue, May 15, 2012 at 12:57:37PM -0400, Magnus Hagander wrote:
 On Fri, May 11, 2012 at 11:44 AM, Andrew Dunstan and...@dunslane.net wrote:
 
 
  On 05/11/2012 05:32 AM, Magnus Hagander wrote:
 
 
  But in the interest of actually being productive - what *is* the
  usecase for needing a 5 minute turnaround time? I don't buy the check
  what a patch looks like, because that should be done *before* the
  commit, not after - so it's best verified by a local docs build anyway
  (which will also be faster).
 
  I'm sure we can put something in with a pretty quick turnaround again
  without too much strain on the system, but it does, as I mentioned
  before, require decoupling it from the buildfarm which means it's not
  just tweaking a config file.
 
 
  If it's of any use to you I have made some adjustments to the buildfarm code
  which would let you do *just* the docs build (and dist make if you want). It
  would still pull from git, and only do anything if there's a (relevant)
  change. So using that to set up a machine that would run every few minutes
  might work. Of course, building the docs can itself be fairly compute
  intensive, so you still might not want to run every few minutes if that's a
  limiting factor.
 
 that would definitely be useful. Compute intensive is not really a
 problem, we can easily shape the box on that (and I think we already
 do).
 
 Do you have some details of what to do and how to do it to use that,
 so Stefan can set it up for us ? ;)

Where are we on building the development docs more frequently?

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

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

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

2012-05-31 Thread Magnus Hagander

On Thu, May 31, 2012 at 5:55 PM, Bruce Momjian br...@momjian.us wrote:
 On Tue, May 15, 2012 at 12:57:37PM -0400, Magnus Hagander wrote:
 On Fri, May 11, 2012 at 11:44 AM, Andrew Dunstan and...@dunslane.net wrote:
 
 
  On 05/11/2012 05:32 AM, Magnus Hagander wrote:
 
 
  But in the interest of actually being productive - what *is* the
  usecase for needing a 5 minute turnaround time? I don't buy the check
  what a patch looks like, because that should be done *before* the
  commit, not after - so it's best verified by a local docs build anyway
  (which will also be faster).
 
  I'm sure we can put something in with a pretty quick turnaround again
  without too much strain on the system, but it does, as I mentioned
  before, require decoupling it from the buildfarm which means it's not
  just tweaking a config file.
 
 
  If it's of any use to you I have made some adjustments to the buildfarm 
  code
  which would let you do *just* the docs build (and dist make if you want). 
  It
  would still pull from git, and only do anything if there's a (relevant)
  change. So using that to set up a machine that would run every few minutes
  might work. Of course, building the docs can itself be fairly compute
  intensive, so you still might not want to run every few minutes if that's a
  limiting factor.

 that would definitely be useful. Compute intensive is not really a
 problem, we can easily shape the box on that (and I think we already
 do).

 Do you have some details of what to do and how to do it to use that,
 so Stefan can set it up for us ? ;)

 Where are we on building the development docs more frequently?

Still waiting for details on how it works to set that up on the
buildfarm client.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.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] Draft release notes complete

2012-05-25 Thread Josh Berkus

On 5/24/12 2:34 PM, Peter Geoghegan wrote:
 On 21 May 2012 19:10, Josh Berkus j...@agliodbs.com wrote:

 For these reasons, it may be timely and appropriate, from a purely
 advocacy point-of-view, to call our new group commit group commit in
 release notes and documentation, and announce it as a new feature.

 First, shouldn't we be having this discussion on -advocacy?
 
 Well, no, because this is a specific discussion about release notes.

True, but there's also the question of what we call this in the
promotional materials.

 In any case, I've given up on the idea that we should market new group
 commit as group commit. I believe that that would be a useful and
 fair way of representing the feature, but there doesn't seem to be any
 support for that view.

What else would you call it?  What's wrong with Better Group Commit?

From my perspective, it's pretty simple: we had group commit before, but
the new group commit is much better.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.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] Draft release notes complete

2012-05-24 Thread Peter Geoghegan

On 21 May 2012 19:10, Josh Berkus j...@agliodbs.com wrote:

 For these reasons, it may be timely and appropriate, from a purely
 advocacy point-of-view, to call our new group commit group commit in
 release notes and documentation, and announce it as a new feature.

 First, shouldn't we be having this discussion on -advocacy?

Well, no, because this is a specific discussion about release notes.
In any case, I've given up on the idea that we should market new group
commit as group commit. I believe that that would be a useful and
fair way of representing the feature, but there doesn't seem to be any
support for that view.

In passing, I noticed this:


E.1.3.12.2. pg_stat_statements

Improve pg_stat_statements to aggregate similar queries (Peter
Geoghegan, Tom Lane)

Improve pg_stat_statements' handling of PREPARE/EXECUTE statements (Tom Lane)

Add dirtied and written block counts to pg_stat_statements (Robert Haas)


I think that the second entry should be listed as a bug fix, or a
compatibility note, rather than an actual feature. At the very least,
it should be listed after Add dirtied and written block counts. I
also think that we should separately list as a feature
pg_stat_statements new ability to track I/O timings at the query
granularity.

Are we any closer to a list of major features?

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and 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] Draft release notes complete

2012-05-24 Thread Bruce Momjian

On Thu, May 24, 2012 at 10:34:22PM +0100, Peter Geoghegan wrote:
 In passing, I noticed this:
 
 
 E.1.3.12.2. pg_stat_statements
 
 Improve pg_stat_statements to aggregate similar queries (Peter
 Geoghegan, Tom Lane)
 
 Improve pg_stat_statements' handling of PREPARE/EXECUTE statements (Tom Lane)
 
 Add dirtied and written block counts to pg_stat_statements (Robert Haas)
 
 
 I think that the second entry should be listed as a bug fix, or a
 compatibility note, rather than an actual feature. At the very least,
 it should be listed after Add dirtied and written block counts. I
 also think that we should separately list as a feature

OK, item moved down.  We have not have bug fix designation.  You have
a suggestion?

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

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

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

2012-05-24 Thread Peter Geoghegan

On 24 May 2012 22:57, Bruce Momjian br...@momjian.us wrote:
OK, item moved down. We have not have bug fix designation. You have
a suggestion?

I assumed you were going to put it beside the other compatibility note
relating to pg_stat_statements, Change pg_stat_statements' total_time
column to be measured in milliseconds (Tom Lane).

The Improve pg_stat_statements' handling of PREPARE/EXECUTE
statements is just a way of preventing SQL PREPARE and EXECUTE
utility statements from being double counted in various ways as both
utility statements and optimisable statements. No one actually noticed
this before, and it wouldn't have been feasible to fix in back
branches, I think. Here are the relevant comments:

* If it's an EXECUTE statement, we don't track it and don't increment
* the nesting level. This allows the cycles to be charged to the
* underlying PREPARE instead (by the Executor hooks), which is much more
* useful.
*
* We also don't track execution of PREPARE. If we did, we would get one
* hash table entry for the PREPARE (with hash calculated from the query
* string), and then a different one with the same query string (but hash
* calculated from the query tree) would be used to accumulate costs of
* ensuing EXECUTEs. This would be confusing, and inconsistent with other
* cases where planning time is not included at all.

Also, as I've said, this I/O timings thing certainly deserves to be
separately listed as a new pg_stat_statements feature:

http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5b4f346611431361339253203d486789e4babb02

--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and 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] Draft release notes complete

2012-05-24 Thread Bruce Momjian

On Thu, May 24, 2012 at 11:16:28PM +0100, Peter Geoghegan wrote:
 On 24 May 2012 22:57, Bruce Momjian br...@momjian.us wrote:
  OK, item moved down.  We have not have bug fix designation.  You have
  a suggestion?
 
 I assumed you were going to put it beside the other compatibility note
 relating to pg_stat_statements, Change pg_stat_statements' total_time
 column to be measured in milliseconds (Tom Lane).
 
 The Improve pg_stat_statements' handling of PREPARE/EXECUTE
 statements is just a way of preventing SQL PREPARE and EXECUTE
 utility statements from being double counted in various ways as both
 utility statements and optimisable statements. No one actually noticed
 this before, and it wouldn't have been feasible to fix in back
 branches, I think. Here are the relevant comments:
 
   * If it's an EXECUTE statement, we don't track it and don't increment
   * the nesting level.  This allows the cycles to be charged to the
   * underlying PREPARE instead (by the Executor hooks), which is much more
   * useful.
   *
   * We also don't track execution of PREPARE.  If we did, we would get one
   * hash table entry for the PREPARE (with hash calculated from the query
   * string), and then a different one with the same query string (but hash
   * calculated from the query tree) would be used to accumulate costs of
   * ensuing EXECUTEs.  This would be confusing, and inconsistent with other
   * cases where planning time is not included at all.

OK, I updated the wording on this, but don't see it as something
incompatibile, in the same way that the others listed are incompatible.

 
 Also, as I've said, this I/O timings thing certainly deserves to be
 separately listed as a new pg_stat_statements feature:
 
 http://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5b4f346611431361339253203d486789e4babb02

OK, I merged that into the existing item.  Applied patch attached.

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

  + It's impossible for everything to be true. +
diff --git a/doc/src/sgml/release-9.2.sgml b/doc/src/sgml/release-9.2.sgml
new file mode 100644
index 90bb9c0..e4152e7
*** a/doc/src/sgml/release-9.2.sgml
--- b/doc/src/sgml/release-9.2.sgml
***
*** 2741,2755 
  
listitem
 para
! Add dirtied and written block counts to
! applicationpg_stat_statements/ (Robert Haas)
 /para
/listitem
  
listitem
 para
! Improve applicationpg_stat_statements/' handling of
! commandPREPARE/command/commandEXECUTE/command statements
  (Tom Lane)
 /para
/listitem
--- 2741,2755 
  
listitem
 para
! Add dirtied and written block counts and read/write times to
! applicationpg_stat_statements/ (Robert Haas, Ants Aasma)
 /para
/listitem
  
listitem
 para
! Prevent applicationpg_stat_statements/ from double-counting
! commandPREPARE/command and commandEXECUTE/command commands
  (Tom Lane)
 /para
/listitem

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

2012-05-22 Thread Robert Haas

On Mon, May 21, 2012 at 9:54 PM, Noah Misch n...@leadboat.com wrote:
 On Wed, May 09, 2012 at 11:11:02PM -0400, Bruce Momjian wrote:
 I have completed my draft of the 9.2 release notes, and committed it to
 git.

 Concerning Have psql \copy use libpq's SendQuery(), SendQuery() is a
 psql-internal interface, not a libpq interface.

 The array statistics patch added new columns to the pg_stats view, and it
 moved existing tsvector most-common-element statistics to those new columns.
 Let's mention that as a (minor) incompatibility.

 Proposed changes attached.

Committed.

-- 
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

Re: [HACKERS] Draft release notes complete

On Wed, May 16, 2012 at 05:30:27PM -0400, Bruce Momjian wrote:
 
 I will make the adjustments outlined below as soon as I can.

Done and committed.

---

 
 On Sun, May 13, 2012 at 12:37:52AM -0400, Robert Haas wrote:
  On Sat, May 12, 2012 at 8:11 PM, Euler Taveira eu...@timbira.com wrote:
   On 12-05-2012 10:27, Bruce Momjian wrote:
   How many names on a single item is ideal?  The activity of reviewers and
   their names on commit messages has greatly expanded the number of
   potential names per item.
  
   Main authors only. Reviewers should be mentioned only in the commit log. 
   If I
   coded a feature and Bruce got the idea worked in another patch (that is 
   better
   then mine), I think only Bruce should be credited in release notes (but I
   could be mentioned in the commit log as the feature designer). However, 
   if I
   posted a patch and Robert improved that patch using only 30% of my work, I
   should be credited (as coauthor) because he used a considerable part of 
   my work.
  
  Completely agreed.  If we're going to include names in the release
  notes, I agree that this is the way to do it, and I think it's what we
  have done in prior releases.
  
  I tend to err on the side of crediting people in the commit message
  (of course, occasionally I forget someone who should have been
  included), but I also try to make it clear by the phrasing whose code
  got included and who contributed in some other way - e.g. by reporting
  the problem, coming up with the original idea, or reviewing.  I do
  this in part because I assumed that we'd use that as the criteria for
  including names in the release notes, as we have done in prior
  releases.  So if I write:
  
  Euler Taveira, reviewed by Bruce Momjian, substantially rewritten by me
  
  ...then I expect that to turn up in the release notes as (Euler
  Taveira, Robert Haas).  If I write:
  
  Euler Taveira, reviewed by Bruce Momjian, with minor cleanup by me
  
  ...then I expect that to turn up as (Euler Taveira).  And if I write
  something like:
  
  Inspired by a patch from Euler Taveira.  Review (in earlier versions)
  by Bruce Momjian.
  
  ...then I expect that to turn up as (Robert Haas) or (Robert Haas,
  Euler Taveira).
  
  In doubtful cases, I think it's generally appropriate to err on the
  side of crediting the person who was the original driving force behind
  the patch, and also to err on the side of not crediting the committer.
   But if the committer chopped up the patch and committed something
  significantly different from the original, then they should be
  credited - or blamed - for the result.
  
  -- 
  Robert Haas
  EnterpriseDB: http://www.enterprisedb.com
  The Enterprise PostgreSQL Company
 
 -- 
   Bruce Momjian  br...@momjian.ushttp://momjian.us
   EnterpriseDB http://enterprisedb.com
 
   + It's impossible for everything to be true. +
 
 -- 
 Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-hackers

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

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

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

On Thu, May 10, 2012 at 10:22:58PM +0400, Alexander Korotkov wrote:
 Improve GiST box and point index performance by producing better trees with
 less memory allocation overhead (Alexander Korotkov, Heikki Linnakangas, Kevin
 Grittner)
 Is this note about following two commits?
 http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=
 7f3bd86843e5aad84585a57d3f6b80db3c609916
 http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=
 d50e1251946a6e59092f0a84fc903532eb599a4f
 These improvements influence not only boxes and points but all geometrical
 datatypes.

OK, new wording:

Improve GiST geometric type index performance by producing better
trees with less memory allocation overhead (Alexander Korotkov)

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

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

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

On Wed, May 16, 2012 at 10:49:25PM +0300, Heikki Linnakangas wrote:
 On 16.05.2012 22:38, Jeff Janes wrote:
 For item:
 Improve COPY performance by adding tuples to the heap in batches
 (Heikki Linnakangas)
 
 I think we should point out that the batching only applies for COPY
 into unindexed tables.  Nice as the feature is, that is pretty big
 limitation not to mention.
 
 No, it applies to indexed tables too. However, if there are indexes
 on the table, the overhead of updating the indexes will probably
 make any speedup in the heap insertions look tiny in comparison.
 
 The optimization doesn't apply if the table has BEFORE or INSTEAD OF
 triggers, or volatile DEFAULT expressions need to be evaluated.

So, I will assume the existing wording is fine.

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

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

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

2012-05-22 Thread Alexander Korotkov

On Wed, May 23, 2012 at 1:26 AM, Bruce Momjian br...@momjian.us wrote:

 On Thu, May 10, 2012 at 10:22:58PM +0400, Alexander Korotkov wrote:
  Improve GiST box and point index performance by producing better trees
 with
  less memory allocation overhead (Alexander Korotkov, Heikki Linnakangas,
 Kevin
  Grittner)
  Is this note about following two commits?
  http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=
  7f3bd86843e5aad84585a57d3f6b80db3c609916
  http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=
  d50e1251946a6e59092f0a84fc903532eb599a4f
  These improvements influence not only boxes and points but all
 geometrical
  datatypes.

 OK, new wording:

Improve GiST geometric type index performance by producing better
trees with less memory allocation overhead (Alexander Korotkov)


Thanks!

Also, I've some notes about removing reviewers.
Improve GiST index build times (Alexander Korotkov)
I think Heikki Linnakangas should be also listed as author of that patch
because he didn't only review and commit, but actually put his hands on
code.

Isn't my authorship of this patch lost now?
http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=80da9e68fdd70b796b3a7de3821589513596c0f7
I think earlier this patch was taken into account in entry Add support for
range data types. Probably, we need separate entry for this patch?

--
With best regards,
Alexander Korotkov.

Re: [HACKERS] Draft release notes complete

On Wed, May 23, 2012 at 01:38:06AM +0400, Alexander Korotkov wrote:
 On Wed, May 23, 2012 at 1:26 AM, Bruce Momjian br...@momjian.us wrote:
 
 On Thu, May 10, 2012 at 10:22:58PM +0400, Alexander Korotkov wrote:
  Improve GiST box and point index performance by producing better trees
 with
  less memory allocation overhead (Alexander Korotkov, Heikki Linnakangas,
 Kevin
  Grittner)
  Is this note about following two commits?
  http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=
  7f3bd86843e5aad84585a57d3f6b80db3c609916
  http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=
  d50e1251946a6e59092f0a84fc903532eb599a4f
  These improvements influence not only boxes and points but all
 geometrical
  datatypes.
 
 OK, new wording:
 
Improve GiST geometric type index performance by producing better
trees with less memory allocation overhead (Alexander Korotkov)
 
 
 Thanks!
 
 Also, I've some notes about removing reviewers.
 Improve GiST index build times (Alexander Korotkov)
 I think Heikki Linnakangas should be also listed as author of that patch
 because he didn't only review and commit, but actually put his hands on code.

OK, Heikki added.

 Isn't my authorship of this patch lost now?
 http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=
 80da9e68fdd70b796b3a7de3821589513596c0f7
 I think earlier this patch was taken into account in entry Add support for
 range data types. Probably, we need separate entry for this patch?

I thought that was more of a Gist index improvement than a range type
improvement, but I have added your name to the range type item.

Thanks.

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

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

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

2012-05-21 Thread Josh Berkus


 For these reasons, it may be timely and appropriate, from a purely
 advocacy point-of-view, to call our new group commit group commit in
 release notes and documentation, and announce it as a new feature.

First, shouldn't we be having this discussion on -advocacy?

To date, I've been calling it better group commit.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.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] Draft release notes complete

2012-05-21 Thread Noah Misch

On Wed, May 09, 2012 at 11:11:02PM -0400, Bruce Momjian wrote:
 I have completed my draft of the 9.2 release notes, and committed it to
 git.

Concerning Have psql \copy use libpq's SendQuery(), SendQuery() is a
psql-internal interface, not a libpq interface.

The array statistics patch added new columns to the pg_stats view, and it
moved existing tsvector most-common-element statistics to those new columns.
Let's mention that as a (minor) incompatibility.

Proposed changes attached.

Thanks,
nm
*** a/doc/src/sgml/release-9.2.sgml
--- b/doc/src/sgml/release-9.2.sgml
***
*** 109,114 
--- 109,129 
 /para
/listitem
  
+   listitem
+para
+ Move typetsvector/ most-common-element statistics to new
+ link linkend=view-pg-statsstructnamepg_stats// columns
+ (Alexander Korotkov)
+/para
+ 
+para
+ Consult structnamemost_common_elems/
+ and structnamemost_common_elem_freqs/ for the data formerly
+ available in structnamemost_common_vals/
+ and structnamemost_common_freqs/.
+/para
+   /listitem
+ 
  /itemizedlist
  
  sect4
***
*** 2125,2137 
  
listitem
 para
! Have applicationpsql/ command\copy/ use libpq's
! functionSendQuery()/ (Noah Misch)
 /para
  
 para
! This makes command\copy/ failure behavior more predictable,
! and honors envarON_ERROR_ROLLBACK/.
 /para
/listitem
  
--- 2140,2152 
  
listitem
 para
! Unify and tighten applicationpsql/ treatment of command\copy/
! and plain commandCOPY/ (Noah Misch)
 /para
  
 para
! This makes failure behavior more predictable and honors command\set
! ON_ERROR_ROLLBACK/.
 /para
/listitem
  

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

2012-05-16 Thread Jeff Janes

On Wed, May 9, 2012 at 8:11 PM, Bruce Momjian br...@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=guaibasaurusdt=lateststg=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


For item:
Improve COPY performance by adding tuples to the heap in batches
(Heikki Linnakangas)

I think we should point out that the batching only applies for COPY
into unindexed tables.  Nice as the feature is, that is pretty big
limitation not to mention.

Also, I wouldn't use to the heap, as I think the main improvement is
from the batching of the wal records, not the heap, and also because
the basic improvement (get data into TABLES faster) can be understood
by users who don't know what a heap is, so we should avoid referring
to extraneous implementation details when they are not critical to
understanding the feature.

Thanks,

Jeff

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

2012-05-16 Thread Heikki Linnakangas


On 16.05.2012 22:38, Jeff Janes wrote:

For item:
Improve COPY performance by adding tuples to the heap in batches
(Heikki Linnakangas)

I think we should point out that the batching only applies for COPY
into unindexed tables.  Nice as the feature is, that is pretty big
limitation not to mention.


No, it applies to indexed tables too. However, if there are indexes on 
the table, the overhead of updating the indexes will probably make any 
speedup in the heap insertions look tiny in comparison.


The optimization doesn't apply if the table has BEFORE or INSTEAD OF 
triggers, or volatile DEFAULT expressions need to be evaluated.


--
  Heikki Linnakangas
  EnterpriseDB   http://www.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] Draft release notes complete

2012-05-16 Thread Bruce Momjian


I will make the adjustments outlined below as soon as I can.

---

On Sun, May 13, 2012 at 12:37:52AM -0400, Robert Haas wrote:
 On Sat, May 12, 2012 at 8:11 PM, Euler Taveira eu...@timbira.com wrote:
  On 12-05-2012 10:27, Bruce Momjian wrote:
  How many names on a single item is ideal?  The activity of reviewers and
  their names on commit messages has greatly expanded the number of
  potential names per item.
 
  Main authors only. Reviewers should be mentioned only in the commit log. If 
  I
  coded a feature and Bruce got the idea worked in another patch (that is 
  better
  then mine), I think only Bruce should be credited in release notes (but I
  could be mentioned in the commit log as the feature designer). However, if I
  posted a patch and Robert improved that patch using only 30% of my work, I
  should be credited (as coauthor) because he used a considerable part of my 
  work.
 
 Completely agreed.  If we're going to include names in the release
 notes, I agree that this is the way to do it, and I think it's what we
 have done in prior releases.
 
 I tend to err on the side of crediting people in the commit message
 (of course, occasionally I forget someone who should have been
 included), but I also try to make it clear by the phrasing whose code
 got included and who contributed in some other way - e.g. by reporting
 the problem, coming up with the original idea, or reviewing.  I do
 this in part because I assumed that we'd use that as the criteria for
 including names in the release notes, as we have done in prior
 releases.  So if I write:
 
 Euler Taveira, reviewed by Bruce Momjian, substantially rewritten by me
 
 ...then I expect that to turn up in the release notes as (Euler
 Taveira, Robert Haas).  If I write:
 
 Euler Taveira, reviewed by Bruce Momjian, with minor cleanup by me
 
 ...then I expect that to turn up as (Euler Taveira).  And if I write
 something like:
 
 Inspired by a patch from Euler Taveira.  Review (in earlier versions)
 by Bruce Momjian.
 
 ...then I expect that to turn up as (Robert Haas) or (Robert Haas,
 Euler Taveira).
 
 In doubtful cases, I think it's generally appropriate to err on the
 side of crediting the person who was the original driving force behind
 the patch, and also to err on the side of not crediting the committer.
  But if the committer chopped up the patch and committed something
 significantly different from the original, then they should be
 credited - or blamed - for the result.
 
 -- 
 Robert Haas
 EnterpriseDB: http://www.enterprisedb.com
 The Enterprise PostgreSQL Company

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

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

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

2012-05-15 Thread Robert Haas

On Mon, May 14, 2012 at 3:21 PM, Peter Geoghegan pe...@2ndquadrant.com wrote:
 The mere ability to notice that an XLogFlush() call is unnecessary and
 fastpath out could be argued to be an aboriginal group commit,
 predating even commit_delay, as could skipping duplicate fsync()
 requests in XLogWrite(), which I think Jeff pointed out, but I don't
 think anyone actually takes this position.

Well, Tom appears to have to have he'd implemented group commit in 2002.

http://archives.postgresql.org/pgsql-hackers/2002-10/msg00331.php

More accurately, he seems to have thought that group commit was
already there, and he'd improved it.  So saying that we're getting it
for the first time ten years later seems pretty odd to me.

I don't deny that the new feature is a significant improvement under
the right circumstances.  But I still maintain it's an improvement of
something that was already there, rather than something new.

-- 
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

Re: [HACKERS] Draft release notes complete

2012-05-15 Thread Magnus Hagander

On Fri, May 11, 2012 at 11:44 AM, Andrew Dunstan and...@dunslane.net wrote:


 On 05/11/2012 05:32 AM, Magnus Hagander wrote:


 But in the interest of actually being productive - what *is* the
 usecase for needing a 5 minute turnaround time? I don't buy the check
 what a patch looks like, because that should be done *before* the
 commit, not after - so it's best verified by a local docs build anyway
 (which will also be faster).

 I'm sure we can put something in with a pretty quick turnaround again
 without too much strain on the system, but it does, as I mentioned
 before, require decoupling it from the buildfarm which means it's not
 just tweaking a config file.


 If it's of any use to you I have made some adjustments to the buildfarm code
 which would let you do *just* the docs build (and dist make if you want). It
 would still pull from git, and only do anything if there's a (relevant)
 change. So using that to set up a machine that would run every few minutes
 might work. Of course, building the docs can itself be fairly compute
 intensive, so you still might not want to run every few minutes if that's a
 limiting factor.

that would definitely be useful. Compute intensive is not really a
problem, we can easily shape the box on that (and I think we already
do).

Do you have some details of what to do and how to do it to use that,
so Stefan can set it up for us ? ;)

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.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] Draft release notes complete

2012-05-15 Thread Greg Sabino Mullane


-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160


Bruce wrote:
 In summary, names on release note items potentially have the 
 following beneficial effects:

 *  Encouraging new developers/reviewers
 *  Encouraging long-established developers
 *  Showing appreciation to developers
 *  Assisting future employment for developers
 *  Helping developers get future funding
 *  Assigning responsibility for features
 *  Showing Postgres's increased developer base

The only important ones are:

 * Assisting future employment for developers
 * Helping developers get future funding
 * Assigning responsibility for features
 * Assigning blame for feature problems

That last one is not very important either. If there is a bug, 
you report it. The original author may or may not handle it.

A better way to state some of the above is:

* Quick cross-reference of a person to a feature.

If I claim to have written ON_ERROR_ROLLBACK, nobody should have 
to scroll back through git logs to confirm or deny. (For that matter, 
we should do everything possible to prevent anyone from using 
git log, especially non-developers, for any meta-information.)

+1 to keep things they way they are. If you were significantly invested 
in [re]writing the patch, you get a name. Reviewers, I love you dearly, 
but you don't belong next to the patch. Group them all at the bottom 
if we must have them there.

- -- 
Greg Sabino Mullane g...@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201205151259
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-BEGIN PGP SIGNATURE-

iEYEAREDAAYFAk+yi3cACgkQvJuQZxSWSsiAcACfYC1HCxbMor/c0EJF6kn+XKc9
kOcAoMn0vnOJLa8+HVz5oWKAZxjkOtQi
=eiUT
-END PGP SIGNATURE-



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

2012-05-15 Thread Greg Sabino Mullane


-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160


 I'd vote for starting a separate thread to solicit people's opinions
 on whether we need names in the release notes.  Is there anybody on
 -hackers who would be offended, or would have a harder time persuading
 $BOSS to let them spend time on Postgres if they weren't mentioned in
 the release notes?  There'd still be a policy of crediting people in
 commit messages of course, but it's not clear to me whether the release
 note mentions are important to anybody.

Looks like this is mostly answered, and we obviously don't need another 
thread, but the answer to the above is yes.

Release notes are very public, plain text, easy to read, very archived 
and searchable. Commit messages might as well be a black hole as far as 
visibility to anyone not a developer in the project.

- -- 
Greg Sabino Mullane g...@turnstep.com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201205151301
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-BEGIN PGP SIGNATURE-

iEYEAREDAAYFAk+yjFEACgkQvJuQZxSWSsi3gACgmikPzvshZPftTuEdmcB8/Ply
4vMAn1DxvG6hntfxJzWRDdPyWlP5X7WM
=pUbl
-END PGP SIGNATURE-



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

2012-05-15 Thread Peter Geoghegan

On 15 May 2012 17:51, Robert Haas robertmh...@gmail.com wrote:
 More accurately, he seems to have thought that group commit was
 already there, and he'd improved it.  So saying that we're getting it
 for the first time ten years later seems pretty odd to me.

Maybe it's odd, and maybe it's inconsistent with earlier terminology
that was privately used, and maybe I'm just plain wrong. Nevertheless,
it is my position that:

1. Group commit isn't a rigorously defined term, which sure is
apparent by our confusion. So even if you're right, that's only by
virtue of a precedent being set regarding the terminology, for which
there could just as easily have been another precedent without there
having to be substantive differences to the code, had things happened
to go that way.

2. Group commit is associated in people's minds with results that look
much like the results we can now show. It is my understanding that we
couldn't show improvements like this before. So while group commit
isn't rigorously defined, people have a certain vague set of
expectations about it that we previously basically failed to meet.

For these reasons, it may be timely and appropriate, from a purely
advocacy point-of-view, to call our new group commit group commit in
release notes and documentation, and announce it as a new feature.

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and 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] Draft release notes complete

2012-05-14 Thread Bruce Momjian

On Sun, May 13, 2012 at 09:01:03PM +0100, Peter Geoghegan wrote:
 On 12 May 2012 01:37, Robert Haas robertmh...@gmail.com wrote:
  Right.  It's not a new feature; it's a performance improvement.  We've
  had group commit for a long time; it just didn't work very well
  before.  And it's not batching the commits better; it's reducing the
  lock contention around realizing that the batched commit has happened.
 
 This understanding of group commit is technically accurate, but the
 practical implications of the new code are that lots of people benefit
 from group commit, potentially to rather a large degree, where before
 they had exactly no benefit from group commit. We never officially
 called group commit group commit outside of git commit messages
 before. Therefore, it is sort of like we didn't have group commit
 before but now we do, and it's an implementation that's probably as
 effective as that of any of our competitors. It is for that reason
 that I suggested group commit get a more prominent billing, and that
 it actually be officially referred to as group commit. I'm glad that
 the release notes now actually refer to group commit.
 
 Now, I realise that as one of the authors of the feature I am open to
 accusations of lacking objectivity - clearly it isn't really my place
 to try and influence the feature's placement, and this is the last I
 will say on the matter unless someone else brings it up again. I just
 think that pedantically characterising this as an improvement to our
 existing group commit implementation within a document that will be
 read like a press release is a bad decision, especially since our
 competitors never had a group commit implementation that was far
 inferior to their current implementation. The assumption will be that
 it's a small improvement that's hardly worth noticing at all.

Thanks for the summary. I know we talk about group commit, but I wasn't
aware that it had not been exposed to our general users.  I agree we
need to reword the item as you suggested.  So this group commit happens
even if users don't change these?

#commit_delay = 0   # range 0-10, in microseconds
#commit_siblings = 5# range 1-1000

So the new release item wording will be:

Add group commit capability for sessions that commit at the same
time

This is the git commit message:

Make group commit more effective.

When a backend needs to flush the WAL, and someone else is already flushing
the WAL, wait until it releases the WALInsertLock and check if we still need
to do the flush or if the other backend already did the work for us, before
acquiring WALInsertLock. This helps group commit, because when the WAL flush
finishes, all the backends that were waiting for it can be woken up in one
go, and the can all concurrently observe that they're done, rather than
waking them up one by one in a cascading fashion.

This is based on a new LWLock function, LWLockWaitUntilFree(), which has
peculiar semantics. If the lock is immediately free, it grabs the lock and
returns true. If it's not free, it waits until it is released, but then
returns false without grabbing the lock. This is used in XLogFlush(), so
that when the lock is acquired, the backend flushes the WAL, but if it's
not, the backend first checks the current flush location before retrying.

Original patch and benchmarking by Peter Geoghegan and Simon Riggs, although
this patch as committed ended up being very different from that.

(Heikki Linnakangas)

Is that commit message inaccurate?

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

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

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

2012-05-14 Thread Robert Haas

On May 14, 2012, at 9:06 AM, Bruce Momjian br...@momjian.us wrote:
 So the new release item wording will be:
 
Add group commit capability for sessions that commit at the same
time
 
 This is the git commit message:
 
Make group commit more effective.
 
When a backend needs to flush the WAL, and someone else is already flushing
the WAL, wait until it releases the WALInsertLock and check if we still 
 need
to do the flush or if the other backend already did the work for us, before
acquiring WALInsertLock. This helps group commit, because when the WAL 
 flush
finishes, all the backends that were waiting for it can be woken up in one
go, and the can all concurrently observe that they're done, rather than
waking them up one by one in a cascading fashion.
 
This is based on a new LWLock function, LWLockWaitUntilFree(), which has
peculiar semantics. If the lock is immediately free, it grabs the lock and
returns true. If it's not free, it waits until it is released, but then
returns false without grabbing the lock. This is used in XLogFlush(), so
that when the lock is acquired, the backend flushes the WAL, but if it's
not, the backend first checks the current flush location before retrying.
 
Original patch and benchmarking by Peter Geoghegan and Simon Riggs, 
 although
this patch as committed ended up being very different from that.
 
(Heikki Linnakangas)
 
 Is that commit message inaccurate?

No, I think it's actually more accurate than the proposed release note wording.

...Robert
-- 
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] Draft release notes complete

2012-05-14 Thread Jeff Janes

On Mon, May 14, 2012 at 9:06 AM, Bruce Momjian br...@momjian.us wrote:
 On Sun, May 13, 2012 at 09:01:03PM +0100, Peter Geoghegan wrote:
 On 12 May 2012 01:37, Robert Haas robertmh...@gmail.com wrote:
  Right.  It's not a new feature; it's a performance improvement.  We've
  had group commit for a long time; it just didn't work very well
  before.  And it's not batching the commits better; it's reducing the
  lock contention around realizing that the batched commit has happened.

 This understanding of group commit is technically accurate, but the
 practical implications of the new code are that lots of people benefit
 from group commit, potentially to rather a large degree, where before
 they had exactly no benefit from group commit. We never officially
 called group commit group commit outside of git commit messages
 before. Therefore, it is sort of like we didn't have group commit
 before but now we do, and it's an implementation that's probably as
 effective as that of any of our competitors. It is for that reason
 that I suggested group commit get a more prominent billing, and that
 it actually be officially referred to as group commit. I'm glad that
 the release notes now actually refer to group commit.

 Now, I realise that as one of the authors of the feature I am open to
 accusations of lacking objectivity - clearly it isn't really my place
 to try and influence the feature's placement, and this is the last I
 will say on the matter unless someone else brings it up again. I just
 think that pedantically characterising this as an improvement to our
 existing group commit implementation within a document that will be
 read like a press release is a bad decision, especially since our
 competitors never had a group commit implementation that was far
 inferior to their current implementation. The assumption will be that
 it's a small improvement that's hardly worth noticing at all.

 Thanks for the summary. I know we talk about group commit, but I wasn't
 aware that it had not been exposed to our general users.  I agree we
 need to reword the item as you suggested.  So this group commit happens
 even if users don't change these?

        #commit_delay = 0           # range 0-10, in microseconds
        #commit_siblings = 5            # range 1-1000

If a bunch of people are standing around waiting for a door to unlock
and they are mutually aware of each other, it has never been the case
(or at least not for years) that the first person through the door
would systematically slam it in everyone else's face.  Is this enough
to qualify as group commit?  If so, group commit has always
(again, at least for years) been there.  The new code simply makes it
less likely that the group will trip over each others feet as they all
stream through the door.

The commit_delay settings cover the case where the door unlocks, and
you open it, but then perhaps you stand there for an a few minutes
holding it open in case someone else happens to show up.  This is
pretty much orthogonal to the prior case.  You can not wait for new
people to show up, but trip over the feet of the people already there.
 Or you can wait for new people to show up, then trip over them.  Or
not trip over them, with or without waiting for new arrival.

(For the analogy to work, this particular door refuses to unlock more
than once every 5 minutes.  Maybe it is for a very slow elevator)

 This is the git commit message:

    Make group commit more effective.

    When a backend needs to flush the WAL, and someone else is already flushing
    the WAL, wait until it releases the WALInsertLock and check if we still 
 need
    to do the flush or if the other backend already did the work for us, before
    acquiring WALInsertLock. This helps group commit, because when the WAL 
 flush
    finishes, all the backends that were waiting for it can be woken up in one
    go, and the can all concurrently observe that they're done, rather than
    waking them up one by one in a cascading fashion.

    This is based on a new LWLock function, LWLockWaitUntilFree(), which has
    peculiar semantics. If the lock is immediately free, it grabs the lock and
    returns true. If it's not free, it waits until it is released, but then
    returns false without grabbing the lock. This is used in XLogFlush(), so
    that when the lock is acquired, the backend flushes the WAL, but if it's
    not, the backend first checks the current flush location before retrying.

    Original patch and benchmarking by Peter Geoghegan and Simon Riggs, 
 although
    this patch as committed ended up being very different from that.

    (Heikki Linnakangas)

 Is that commit message inaccurate?

I think the commit message is accurate, other than saying
WALInsertLock where it meant WALWriteLock.

Cheers,

Jeff

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

2012-05-14 Thread Peter Geoghegan

On 14 May 2012 17:06, Bruce Momjian br...@momjian.us wrote:
 So this group commit happens
 even if users don't change these?

        #commit_delay = 0           # range 0-10, in microseconds
        #commit_siblings = 5            # range 1-1000

Yes, that's right - the new group commit is not configurable, and is
used all the time. I believe that very few people ever change these
other settings in production, because it is very risky to tweak them.
Read the description of them in Greg Smith's book for a good example
of what I mean, or read the docs - it is rare that adding delay by
increasing this parameter will actually improve performance. There
may actually be no one that's set commit_delay  0 at all. All these
settings do is insert a sleep of commit_delay microseconds, in the
hope that the call to XLogFlush() will then find that doing work is
unnecessary due to some other session having got there first.

 So the new release item wording will be:

        Add group commit capability for sessions that commit at the same
        time

I'd say that's almost what I'd like to see, because commit_delay falls
far short of the definition of group commit established by other
RDBMSs, which is, I assume, why the term was never used for advocacy
purposes. The old facility could result in batching of commits
specifically by artificially adding latency so that after the delay
the sessions found they could fastpath. While it worked under
artificial conditions, I think it resulted in relatively small
improvements next to new group commit's order-of-magnitude increase in
throughput that was demonstrated for a maximally commit-bound
workload.

The mere ability to notice that an XLogFlush() call is unnecessary and
fastpath out could be argued to be an aboriginal group commit,
predating even commit_delay, as could skipping duplicate fsync()
requests in XLogWrite(), which I think Jeff pointed out, but I don't
think anyone actually takes this position.

What I'd suggest is something like:


Add group commit capability so that when a session commits, other,
concurrent sessions with pending commits will later automatically
check if their commit has been satisfied by the original request (or
even some other, intervening request) before actually proceeding.

This results in a large increase in transaction throughput for
commit-bound workloads, as under these circumstances the actual number
of flush requests will be considerably lower than that of earlier
versions of PostgreSQL.


Now, granted, the number of actual flush requests being so high wasn't
a problem because of any actual number of follow-through duplicate
fsync() system calls (or writes) - XLogWrite() notices them, and
probably has forever (although I read suggestion that some MySQL
flavours might have actually been stupid enough to do so pre group
commit). But in order to be able to notice this, backends previously
had to get the WALWriteLock exclusively. I don't think that these are
the kind of qualifications that belong here though. People rightfully
only care about the practical implications, and whether or not we're
competitive in various respects, such as whether or not we tick the
group commit box, and whether or not we have pretty graphs that are
comparable to those of other database systems.

 This is the git commit message:

    Make group commit more effective.

    When a backend needs to flush the WAL, and someone else is already flushing
    the WAL, wait until it releases the WALInsertLock and check if we still 
 need
    to do the flush or if the other backend already did the work for us, before
    acquiring WALInsertLock. This helps group commit, because when the WAL 
 flush
    finishes, all the backends that were waiting for it can be woken up in one
    go, and the can all concurrently observe that they're done, rather than
    waking them up one by one in a cascading fashion.

    This is based on a new LWLock function, LWLockWaitUntilFree(), which has
    peculiar semantics. If the lock is immediately free, it grabs the lock and
    returns true. If it's not free, it waits until it is released, but then
    returns false without grabbing the lock. This is used in XLogFlush(), so
    that when the lock is acquired, the backend flushes the WAL, but if it's
    not, the backend first checks the current flush location before retrying.

    Original patch and benchmarking by Peter Geoghegan and Simon Riggs, 
 although
    this patch as committed ended up being very different from that.

    (Heikki Linnakangas)

 Is that commit message inaccurate?

I wouldn't say that it's inaccurate. However, if we were to deprecate
commit_delay and commit_siblings, that would be a mere matter of
removing this code (and the GUC stuff itself):

if (CommitDelay  0  enableFsync 
   MinimumActiveBackends(CommitSiblings))
   pg_usleep(CommitDelay);

This code is just before one call (of several) to XLogFlush(). The
guts of the new group commit are in that

Re: [HACKERS] Draft release notes complete

2012-05-14 Thread Jeff Janes

On Mon, May 14, 2012 at 9:56 AM, Jeff Janes jeff.ja...@gmail.com wrote:
 On Mon, May 14, 2012 at 9:06 AM, Bruce Momjian br...@momjian.us wrote:

 This is the git commit message:

    Make group commit more effective.

    When a backend needs to flush the WAL, and someone else is already 
 flushing
    the WAL, wait until it releases the WALInsertLock and check if we still 
 need
    to do the flush or if the other backend already did the work for us, 
 before
    acquiring WALInsertLock. This helps group commit, because when the WAL 
 flush
    finishes, all the backends that were waiting for it can be woken up in one
    go, and the can all concurrently observe that they're done, rather than
    waking them up one by one in a cascading fashion.

    This is based on a new LWLock function, LWLockWaitUntilFree(), which has
    peculiar semantics. If the lock is immediately free, it grabs the lock and
    returns true. If it's not free, it waits until it is released, but then
    returns false without grabbing the lock. This is used in XLogFlush(), so
    that when the lock is acquired, the backend flushes the WAL, but if it's
    not, the backend first checks the current flush location before retrying.

    Original patch and benchmarking by Peter Geoghegan and Simon Riggs, 
 although
    this patch as committed ended up being very different from that.

    (Heikki Linnakangas)

 Is that commit message inaccurate?

 I think the commit message is accurate, other than saying
 WALInsertLock where it meant WALWriteLock.

Sorry, wrong number of negations.  I think the commit message is
accurate, other than

Cheers,

Jeff

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

2012-05-14 Thread Merlin Moncure

On Wed, May 9, 2012 at 10:11 PM, Bruce Momjian br...@momjian.us wrote:
 I have completed my draft of the 9.2 release notes, and committed it to
 git.

The beta release announcement is on postgresql.org with a direct link
to the release notes.  The notes lead off with:

NARRATIVE HERE. Major enhancements include:

MAJOR LIST HERE

That looks a little unfinished -- this is exactly where many people
land to see what's coming with the new release.  Need some help
putting together the major feature list?

merlin

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

2012-05-13 Thread Peter Geoghegan

On 12 May 2012 01:37, Robert Haas robertmh...@gmail.com wrote:
 Right.  It's not a new feature; it's a performance improvement.  We've
 had group commit for a long time; it just didn't work very well
 before.  And it's not batching the commits better; it's reducing the
 lock contention around realizing that the batched commit has happened.

This understanding of group commit is technically accurate, but the
practical implications of the new code are that lots of people benefit
from group commit, potentially to rather a large degree, where before
they had exactly no benefit from group commit. We never officially
called group commit group commit outside of git commit messages
before. Therefore, it is sort of like we didn't have group commit
before but now we do, and it's an implementation that's probably as
effective as that of any of our competitors. It is for that reason
that I suggested group commit get a more prominent billing, and that
it actually be officially referred to as group commit. I'm glad that
the release notes now actually refer to group commit.

Now, I realise that as one of the authors of the feature I am open to
accusations of lacking objectivity - clearly it isn't really my place
to try and influence the feature's placement, and this is the last I
will say on the matter unless someone else brings it up again. I just
think that pedantically characterising this as an improvement to our
existing group commit implementation within a document that will be
read like a press release is a bad decision, especially since our
competitors never had a group commit implementation that was far
inferior to their current implementation. The assumption will be that
it's a small improvement that's hardly worth noticing at all.

As to the question of whether or not we should include author names at
all, I personally wouldn't mind at all if we removed them, if that
would prevent squabbles, which it probably would. However, that's only
because I know that it wouldn't really affect my ability to work on
Postgres during my working day. I don't know that the same thing can
be said at all for people who don't work for one of the handful of
Postgres companies.

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and 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] Draft release notes complete

2012-05-12 Thread Bruce Momjian

On Fri, May 11, 2012 at 08:37:58PM -0400, Robert Haas wrote:
 On Fri, May 11, 2012 at 2:03 PM, Jeff Janes jeff.ja...@gmail.com wrote:
  On Thu, May 10, 2012 at 10:44 AM, Bruce Momjian br...@momjian.us wrote:
  On Thu, May 10, 2012 at 01:11:54PM +0100, Peter Geoghegan 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
 
  I didn't call it group commit because we have settings we used to
  regard as group commit:
 
  My understanding of that patch is that is does not cause group
  commit to happen, but rather when a group commit does happen
  naturally it causes all members of the group to awaken more
  quickly/efficiently than they previously would have.
 
 Right.  It's not a new feature; it's a performance improvement.  We've
 had group commit for a long time; it just didn't work very well
 before.  And it's not batching the commits better; it's reducing the
 lock contention around realizing that the batched commit has happened.
 
  I updated the release docs to call the item group commit because I now
  don't see any reference to that term in our docs.
 
  I don't think I'd mention WAL writing at all, and just say that it
  improves the concurrency of locking around group commits.
 
 +1.

Updated with the attached patch.

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

  + It's impossible for everything to be true. +
diff --git a/doc/src/sgml/release-9.2.sgml b/doc/src/sgml/release-9.2.sgml
new file mode 100644
index fb603d2..4d22ae7
*** a/doc/src/sgml/release-9.2.sgml
--- b/doc/src/sgml/release-9.2.sgml
***
*** 538,545 
  
listitem
 para
! Improve performance of acronymWAL/acronym writes using group
! commit (Peter Geoghegan, Simon Riggs, Heikki Linnakangas)
 /para
/listitem
  
--- 538,545 
  
listitem
 para
! Improve locking performance during group commit (Peter Geoghegan,
! Simon Riggs, Heikki Linnakangas)
 /para
/listitem
  

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

2012-05-12 Thread Bruce Momjian

In summary, names on release note items potentially have the following
beneficial effects:

*  Encouraging new developers/reviewers
*  Encouraging long-established developers
*  Showing appreciation to developers
*  Assisting future employment for developers
*  Helping developers get future funding
*  Assigning responsibility for features
*  Assigning blame for feature problems
*  Showing Postgres's increased developer base

Many of these goals has already been mentioned.  So the question is
which of these is important?  If we emphasize all of them, I am afraid
the name list for each item will be too long to be acceptable.  

How many names on a single item is ideal?  The activity of reviewers and
their names on commit messages has greatly expanded the number of
potential names per item.

How much of a downside is having the names in the release notes?  For
example, we decided that company names shouldn't be on release note
items, so there is a case where we decided names were more of a negative
than a positive.  Are there other negatives?  Do other project release
notes have developer names?  How are these names perceived by our
general readers?

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

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

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

2012-05-12 Thread Euler Taveira

On 12-05-2012 10:27, Bruce Momjian wrote:
 How many names on a single item is ideal?  The activity of reviewers and
 their names on commit messages has greatly expanded the number of
 potential names per item.
 
Main authors only. Reviewers should be mentioned only in the commit log. If I
coded a feature and Bruce got the idea worked in another patch (that is better
then mine), I think only Bruce should be credited in release notes (but I
could be mentioned in the commit log as the feature designer). However, if I
posted a patch and Robert improved that patch using only 30% of my work, I
should be credited (as coauthor) because he used a considerable part of my work.

I confess that I like the link for relevant commit log in the release notes.


-- 
   Euler Taveira de Oliveira - Timbira   http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento

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

2012-05-12 Thread Bruce Momjian

On Sat, May 12, 2012 at 09:11:49PM -0300, Euler Taveira wrote:
 On 12-05-2012 10:27, Bruce Momjian wrote:
  How many names on a single item is ideal?  The activity of reviewers and
  their names on commit messages has greatly expanded the number of
  potential names per item.
  
 Main authors only. Reviewers should be mentioned only in the commit log. If I
 coded a feature and Bruce got the idea worked in another patch (that is better
 then mine), I think only Bruce should be credited in release notes (but I

The old-timers are howling at how funny it is that I would develop a
better patch than anyone!  LOL

 could be mentioned in the commit log as the feature designer). However, if I
 posted a patch and Robert improved that patch using only 30% of my work, I
 should be credited (as coauthor) because he used a considerable part of my 
 work.
 
 I confess that I like the link for relevant commit log in the release notes.

I _do_ have the git hash information in the git logs, so it is trivial
to transfer that into the release notes, but be aware there are often
multiple commits per feature, and I am unclear how we would interface
those links into the SGML.

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

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

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

2012-05-12 Thread Robert Haas

On Sat, May 12, 2012 at 8:11 PM, Euler Taveira eu...@timbira.com wrote:
 On 12-05-2012 10:27, Bruce Momjian wrote:
 How many names on a single item is ideal?  The activity of reviewers and
 their names on commit messages has greatly expanded the number of
 potential names per item.

 Main authors only. Reviewers should be mentioned only in the commit log. If I
 coded a feature and Bruce got the idea worked in another patch (that is better
 then mine), I think only Bruce should be credited in release notes (but I
 could be mentioned in the commit log as the feature designer). However, if I
 posted a patch and Robert improved that patch using only 30% of my work, I
 should be credited (as coauthor) because he used a considerable part of my 
 work.

Completely agreed.  If we're going to include names in the release
notes, I agree that this is the way to do it, and I think it's what we
have done in prior releases.

I tend to err on the side of crediting people in the commit message
(of course, occasionally I forget someone who should have been
included), but I also try to make it clear by the phrasing whose code
got included and who contributed in some other way - e.g. by reporting
the problem, coming up with the original idea, or reviewing.  I do
this in part because I assumed that we'd use that as the criteria for
including names in the release notes, as we have done in prior
releases.  So if I write:

Euler Taveira, reviewed by Bruce Momjian, substantially rewritten by me

...then I expect that to turn up in the release notes as (Euler
Taveira, Robert Haas).  If I write:

Euler Taveira, reviewed by Bruce Momjian, with minor cleanup by me

...then I expect that to turn up as (Euler Taveira).  And if I write
something like:

Inspired by a patch from Euler Taveira.  Review (in earlier versions)
by Bruce Momjian.

...then I expect that to turn up as (Robert Haas) or (Robert Haas,
Euler Taveira).

In doubtful cases, I think it's generally appropriate to err on the
side of crediting the person who was the original driving force behind
the patch, and also to err on the side of not crediting the committer.
 But if the committer chopped up the patch and committed something
significantly different from the original, then they should be
credited - or blamed - for the result.

-- 
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

Re: [HACKERS] Draft release notes complete

2012-05-11 Thread Magnus Hagander

On Thu, May 10, 2012 at 6:28 PM, Peter Eisentraut pete...@gmx.net wrote:
 On tor, 2012-05-10 at 17:31 +0200, Magnus Hagander wrote:
 If people want the main docs building more often that's not really a
 problem other than time - we just need to decouple it from the
 buildfarm and run a separate job for it. It's not rocket science..

 Many years ago, Bruce and myself in particular put in a lot of work to
 make the turnaround time on the docs build less than 5 minutes, based on
 various requests.  I'm disappointed to learn that that was abandoned
 without discussion.  We might as well just put the old job back.

It was not abandoned without discussion in any way.

First of all, the docs still build in 5 minutes.

Second, the 5 minutes docs build link on the website was removed in
*2007*. At the request of Bruce, who maintained it. This request was
(at least according to the commit message and form what I can
remember) made in public on pgsql-www, and thus clearly open for
discussion. At http://archives.postgresql.org/pgsql-www/2007-12/msg00212.php.
Where Bruce claims the other one runs often enough, and nobody
objects.

Third, the regular docs build on the developer box (which I think ran
once / hour?) *did not work* (prior to that it kind of work but often
hung and failed, but at least it tried to run - at this point it
stopped even trying). The current docs build replaced the case when we
had *no developer docs updates at all*, by taking the reasonably quick
and easy fix to run it as part of an existing buildfarm animal and
upload the results.


So where in all this was anything abandoned?


Bruce already suggested putting the old job back on his box, which
he's of course free to do. But since it took almost 5 years before
anybody actually complained about that, maybe it's not really that big
a problem?

And it's already been agreed that increasing the dev docs build back
up to maybe once an hour would make sense.


-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.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] Draft release notes complete

2012-05-11 Thread Peter Eisentraut

On fre, 2012-05-11 at 09:26 +0200, Magnus Hagander wrote:
 On Thu, May 10, 2012 at 6:28 PM, Peter Eisentraut pete...@gmx.net wrote:
  On tor, 2012-05-10 at 17:31 +0200, Magnus Hagander wrote:
  If people want the main docs building more often that's not really a
  problem other than time - we just need to decouple it from the
  buildfarm and run a separate job for it. It's not rocket science..
 
  Many years ago, Bruce and myself in particular put in a lot of work to
  make the turnaround time on the docs build less than 5 minutes, based on
  various requests.  I'm disappointed to learn that that was abandoned
  without discussion.  We might as well just put the old job back.
 
 It was not abandoned without discussion in any way.
 
 First of all, the docs still build in 5 minutes.

That is different from the turnaround time from the commit.

 Second, the 5 minutes docs build link on the website was removed in
 *2007*. At the request of Bruce, who maintained it. This request was
 (at least according to the commit message and form what I can
 remember) made in public on pgsql-www, and thus clearly open for
 discussion. At http://archives.postgresql.org/pgsql-www/2007-12/msg00212.php.
 Where Bruce claims the other one runs often enough, and nobody
 objects.

You are misinterpreting this.  The reason Bruce's link was removed was
that the other (official) build was set to run at the same frequency, so
Bruce's build was exactly redundant.  The requirement/aspiration to have
a few minutes turnaround time continued.

 Third, the regular docs build on the developer box (which I think ran
 once / hour?) *did not work* (prior to that it kind of work but often
 hung and failed, but at least it tried to run - at this point it
 stopped even trying).

If you had any problems with how well they worked, we could have
discussed this.  It's fine if you want to change how they run, and I
have no problem with how they are run now, but I just want to make clear
what requirements led to the setup at the time.

 So where in all this was anything abandoned?

The ability to get a docs build in less than 5 minutes after commit.



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

2012-05-11 Thread Magnus Hagander

On Fri, May 11, 2012 at 9:55 AM, Peter Eisentraut pete...@gmx.net wrote:
 On fre, 2012-05-11 at 09:26 +0200, Magnus Hagander wrote:
 On Thu, May 10, 2012 at 6:28 PM, Peter Eisentraut pete...@gmx.net wrote:
  On tor, 2012-05-10 at 17:31 +0200, Magnus Hagander wrote:
  If people want the main docs building more often that's not really a
  problem other than time - we just need to decouple it from the
  buildfarm and run a separate job for it. It's not rocket science..
 
  Many years ago, Bruce and myself in particular put in a lot of work to
  make the turnaround time on the docs build less than 5 minutes, based on
  various requests.  I'm disappointed to learn that that was abandoned
  without discussion.  We might as well just put the old job back.

 It was not abandoned without discussion in any way.

 First of all, the docs still build in 5 minutes.

 That is different from the turnaround time from the commit.

 Second, the 5 minutes docs build link on the website was removed in
 *2007*. At the request of Bruce, who maintained it. This request was
 (at least according to the commit message and form what I can
 remember) made in public on pgsql-www, and thus clearly open for
 discussion. At http://archives.postgresql.org/pgsql-www/2007-12/msg00212.php.
 Where Bruce claims the other one runs often enough, and nobody
 objects.

 You are misinterpreting this.  The reason Bruce's link was removed was
 that the other (official) build was set to run at the same frequency, so
 Bruce's build was exactly redundant.  The requirement/aspiration to have
 a few minutes turnaround time continued.

But the other (official) build was *not* set to run at the same
frequency. It was set, according to that mail, to run frequently
enough, but it did not run every 5 minutes. at least not the only
cronjob I found back then.


 Third, the regular docs build on the developer box (which I think ran
 once / hour?) *did not work* (prior to that it kind of work but often
 hung and failed, but at least it tried to run - at this point it
 stopped even trying).

 If you had any problems with how well they worked, we could have
 discussed this.  It's fine if you want to change how they run, and I
 have no problem with how they are run now, but I just want to make clear
 what requirements led to the setup at the time.

The entire machine they ran on *died*. Because it had been
unmaintained for many years. and parts was silently upgraded where as
other, incompatible, parts were not. We did actually leave the script
around. It ran for months, failing at step one, and pretty much nobody
complained.

The docs build was *entirely* undocumented (other than the official
cronjob which did *not* run every 5 minutes, but I guess you are
saying there was a second, undocumented, cronjob that ran more often).


But in the interest of actually being productive - what *is* the
usecase for needing a 5 minute turnaround time? I don't buy the check
what a patch looks like, because that should be done *before* the
commit, not after - so it's best verified by a local docs build anyway
(which will also be faster).

I'm sure we can put something in with a pretty quick turnaround again
without too much strain on the system, but it does, as I mentioned
before, require decoupling it from the buildfarm which means it's not
just tweaking a config file.

-- 
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.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] Draft release notes complete

2012-05-11 Thread Cédric Villemain

Le jeudi 10 mai 2012 22:18:30, Alvaro Herrera a écrit :
 It's been said elsewhere that adding all this to the release notes as
 found on the official docs would be too bulky.  How about having a
 second copy of the release notes that contains authorship info as
 proposed by Andrew?  Then the docs could have no names at all, and
 credit would be given by some other page in the website (to which the
 release notes would link).

Maybe we can update/upgrade the page [1] on the website and add per release 
authors/rewviewers/companies/... ?

[1] http://www.postgresql.org/community/contributors/
-- 
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation


signature.asc
Description: This is a digitally signed message part.

Re: [HACKERS] Draft release notes complete

2012-05-11 Thread Bruce Momjian

On Thu, May 10, 2012 at 08:46:56PM -0700, Robert Haas wrote:
 On May 10, 2012, at 4:19 PM, Andrew Dunstan and...@dunslane.net wrote:
  On 05/10/2012 06:15 PM, Tom Lane wrote:
  How about a hybrid: we continue to identify patch authors as now, that is 
  with names attached to the feature/bugfix descriptions, and then have a 
  separate section Other Contributors to recognize patch reviewers and 
  other helpers?
  
  works for me.
 
 Me, too.

That does not work for me.  There is no practical reason for a list of
names to appear in the release notes.  I suggest if we want to do that
that we remove all names from the release notes (as Tom suggested), and
create a wiki for credit, and link to that from the release
announcement.  That would allow us to put company names in there too.

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

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

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

2012-05-11 Thread Andrew Dunstan




On 05/11/2012 08:56 AM, Bruce Momjian wrote:

On Thu, May 10, 2012 at 08:46:56PM -0700, Robert Haas wrote:

On May 10, 2012, at 4:19 PM, Andrew Dunstanand...@dunslane.net  wrote:

On 05/10/2012 06:15 PM, Tom Lane wrote:

How about a hybrid: we continue to identify patch authors as now, that is with names 
attached to the feature/bugfix descriptions, and then have a separate section Other 
Contributors to recognize patch reviewers and other helpers?

works for me.

Me, too.

That does not work for me.  There is no practical reason for a list of
names to appear in the release notes.  I suggest if we want to do that
that we remove all names from the release notes (as Tom suggested), and
create a wiki for credit, and link to that from the release
announcement.  That would allow us to put company names in there too.



I gave you a reason. You might not agree with it but saying that it's no 
reason doesn't make it so. A wiki page will just be duplication, IMNSHO.


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

2012-05-11 Thread Bruce Momjian

On Fri, May 11, 2012 at 09:51:49AM -0400, Andrew Dunstan wrote:
 
 
 On 05/11/2012 08:56 AM, Bruce Momjian wrote:
 On Thu, May 10, 2012 at 08:46:56PM -0700, Robert Haas wrote:
 On May 10, 2012, at 4:19 PM, Andrew Dunstanand...@dunslane.net  wrote:
 On 05/10/2012 06:15 PM, Tom Lane wrote:
 How about a hybrid: we continue to identify patch authors as now, that is 
 with names attached to the feature/bugfix descriptions, and then have a 
 separate section Other Contributors to recognize patch reviewers and 
 other helpers?
 works for me.
 Me, too.
 That does not work for me.  There is no practical reason for a list of
 names to appear in the release notes.  I suggest if we want to do that
 that we remove all names from the release notes (as Tom suggested), and
 create a wiki for credit, and link to that from the release
 announcement.  That would allow us to put company names in there too.
 
 
 I gave you a reason. You might not agree with it but saying that
 it's no reason doesn't make it so. A wiki page will just be
 duplication, IMNSHO.

I mean a reason from the reader/development-process perspective, not
from the perspective of giving a some benefit to contributors.

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

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

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

2012-05-11 Thread Bruce Momjian

On Fri, May 11, 2012 at 10:01:32AM -0400, Bruce Momjian wrote:
 On Fri, May 11, 2012 at 09:51:49AM -0400, Andrew Dunstan wrote:
  
  
  On 05/11/2012 08:56 AM, Bruce Momjian wrote:
  On Thu, May 10, 2012 at 08:46:56PM -0700, Robert Haas wrote:
  On May 10, 2012, at 4:19 PM, Andrew Dunstanand...@dunslane.net  wrote:
  On 05/10/2012 06:15 PM, Tom Lane wrote:
  How about a hybrid: we continue to identify patch authors as now, that 
  is with names attached to the feature/bugfix descriptions, and then 
  have a separate section Other Contributors to recognize patch 
  reviewers and other helpers?
  works for me.
  Me, too.
  That does not work for me.  There is no practical reason for a list of
  names to appear in the release notes.  I suggest if we want to do that
  that we remove all names from the release notes (as Tom suggested), and
  create a wiki for credit, and link to that from the release
  announcement.  That would allow us to put company names in there too.
  
  
  I gave you a reason. You might not agree with it but saying that
  it's no reason doesn't make it so. A wiki page will just be
  duplication, IMNSHO.
 
 I mean a reason from the reader/development-process perspective, not
 from the perspective of giving a some benefit to contributors.

Let me add that I am concerned about the lack of objectivity in many of
the suggestions in this thread.  This has prompted me to think that the
temptation of having names on these release note items is just too
great, and that the names should be removed.

Let me put it this way --- the release notes are read by thousands of
people.  The benefit individuals gather from their names in the release
notes is a small part of the overall value provided by the release notes
to users.  There was a practical need to have names on items in the past
--- that need is no longer present.

I predict that if we twist the release notes to have PR value for
contributors, it will become a prepetual problem and will diminish the
cohesiveness of our group.  I am already personally upset by a few of
the things I have seen on this thread.

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

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

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

2012-05-11 Thread Andrew Dunstan




On 05/11/2012 10:15 AM, Bruce Momjian wrote:

On Fri, May 11, 2012 at 10:01:32AM -0400, Bruce Momjian wrote:

On Fri, May 11, 2012 at 09:51:49AM -0400, Andrew Dunstan wrote:


On 05/11/2012 08:56 AM, Bruce Momjian wrote:

On Thu, May 10, 2012 at 08:46:56PM -0700, Robert Haas wrote:

On May 10, 2012, at 4:19 PM, Andrew Dunstanand...@dunslane.net   wrote:

On 05/10/2012 06:15 PM, Tom Lane wrote:

How about a hybrid: we continue to identify patch authors as now, that is with names 
attached to the feature/bugfix descriptions, and then have a separate section Other 
Contributors to recognize patch reviewers and other helpers?

works for me.

Me, too.

That does not work for me.  There is no practical reason for a list of
names to appear in the release notes.  I suggest if we want to do that
that we remove all names from the release notes (as Tom suggested), and
create a wiki for credit, and link to that from the release
announcement.  That would allow us to put company names in there too.


I gave you a reason. You might not agree with it but saying that
it's no reason doesn't make it so. A wiki page will just be
duplication, IMNSHO.

I mean a reason from the reader/development-process perspective, not
from the perspective of giving a some benefit to contributors.

Let me add that I am concerned about the lack of objectivity in many of
the suggestions in this thread.  This has prompted me to think that the
temptation of having names on these release note items is just too
great, and that the names should be removed.

Let me put it this way --- the release notes are read by thousands of
people.  The benefit individuals gather from their names in the release
notes is a small part of the overall value provided by the release notes
to users.  There was a practical need to have names on items in the past
--- that need is no longer present.

I predict that if we twist the release notes to have PR value for
contributors, it will become a prepetual problem and will diminish the
cohesiveness of our group.  I am already personally upset by a few of
the things I have seen on this thread.



Well, I don't know what has changed that made it imperative in the past 
to have the names and makes it now redundant, nor what could possibly 
have upset you so much. Maybe I'm dense, but that's the truth of it.


Now if someone is going to volunteer to build *AND* *MAINTAIN* a Credits 
page, that will be good. It would be even better if they would go back 
and do it historically. But just hoping that will happen and meantime 
removing the names from the notes seems to me a retrograde step.


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

2012-05-11 Thread Tom Lane

Bruce Momjian br...@momjian.us writes:
 Let me add that I am concerned about the lack of objectivity in many of
 the suggestions in this thread.  This has prompted me to think that the
 temptation of having names on these release note items is just too
 great, and that the names should be removed.

Er, what?  I have not seen anything in this thread that merits such
an accusation.

 Let me put it this way --- the release notes are read by thousands of
 people.  The benefit individuals gather from their names in the release
 notes is a small part of the overall value provided by the release notes
 to users.  There was a practical need to have names on items in the past
 --- that need is no longer present.

My recollection is that we have been putting the names on the items to
(a) give credit where credit is due, and (b) show that Postgres has a
large and growing development community.  I had never heard the argument
remember whom to blame for a broken feature until you raised it
yesterday --- personally, I've always looked in the commit logs if I want
to know something like that.  So I don't see that there's really any
change in the terms of discussion.  It may be that the release notes
aren't the best place for doing either (a) or (b), but I don't agree
that we simply don't need to worry about either anymore.

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

2012-05-11 Thread Andrew Dunstan




On 05/11/2012 05:32 AM, Magnus Hagander wrote:


But in the interest of actually being productive - what *is* the
usecase for needing a 5 minute turnaround time? I don't buy the check
what a patch looks like, because that should be done *before* the
commit, not after - so it's best verified by a local docs build anyway
(which will also be faster).

I'm sure we can put something in with a pretty quick turnaround again
without too much strain on the system, but it does, as I mentioned
before, require decoupling it from the buildfarm which means it's not
just tweaking a config file.


If it's of any use to you I have made some adjustments to the buildfarm 
code which would let you do *just* the docs build (and dist make if you 
want). It would still pull from git, and only do anything if there's a 
(relevant) change. So using that to set up a machine that would run 
every few minutes might work. Of course, building the docs can itself be 
fairly compute intensive, so you still might not want to run every few 
minutes if that's a limiting factor.



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

2012-05-11 Thread Jeff Janes

On Thu, May 10, 2012 at 10:44 AM, Bruce Momjian br...@momjian.us wrote:
 On Thu, May 10, 2012 at 01:11:54PM +0100, Peter Geoghegan 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

 I didn't call it group commit because we have settings we used to
 regard as group commit:

My understanding of that patch is that is does not cause group
commit to happen, but rather when a group commit does happen
naturally it causes all members of the group to awaken more
quickly/efficiently than they previously would have.


        #commit_delay = 0           # range 0-10, in microseconds
        #commit_siblings = 5            # range 1-1000

 These are still there.  Should they be removed?

The new locking around releasing group commit waiters has, if
anything, made these two more effective than before.  But that isn't
really saying much.  It seems like these knobs are (and were)
primarily useful for doing stupid benchmark tricks of little
practical value.  If there is an argument for removing them, I think
it would revolve around either They never really should have been
there anyway, or These days when people need far more commits per
second than they have revolutions per second, they buy BBU or NVRAM.

 I updated the release docs to call the item group commit because I now
 don't see any reference to that term in our docs.

I don't think I'd mention WAL writing at all, and just say that it
improves the concurrency of locking around group commits.

Cheers,

Jeff

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

2012-05-11 Thread Peter Eisentraut

On fre, 2012-05-11 at 11:32 +0200, Magnus Hagander wrote:
  You are misinterpreting this.  The reason Bruce's link was removed was
  that the other (official) build was set to run at the same frequency, so
  Bruce's build was exactly redundant.  The requirement/aspiration to have
  a few minutes turnaround time continued.
 
 But the other (official) build was *not* set to run at the same
 frequency. It was set, according to that mail, to run frequently
 enough, but it did not run every 5 minutes. at least not the only
 cronjob I found back then.

I would love to see what cron job job you are referring to.
Unfortunately, I don't have a backup, but I'm pretty sure at one point
it ran every three minutes or so.

 But in the interest of actually being productive - what *is* the
 usecase for needing a 5 minute turnaround time?

I don't exactly know, it was done at the request of users.  A lot of
people wanted to see the documentation of new checkins, just to learn
about how the new features worked.

As a general point, any delay time is going to raise questions, because
it usually won't be easy to find out when things will happen.  So the
human maintenance effort will be lower if it runs as soon as possible.



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

2012-05-11 Thread Robert Haas

On Fri, May 11, 2012 at 2:03 PM, Jeff Janes jeff.ja...@gmail.com wrote:
 On Thu, May 10, 2012 at 10:44 AM, Bruce Momjian br...@momjian.us wrote:
 On Thu, May 10, 2012 at 01:11:54PM +0100, Peter Geoghegan 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

 I didn't call it group commit because we have settings we used to
 regard as group commit:

 My understanding of that patch is that is does not cause group
 commit to happen, but rather when a group commit does happen
 naturally it causes all members of the group to awaken more
 quickly/efficiently than they previously would have.

Right.  It's not a new feature; it's a performance improvement.  We've
had group commit for a long time; it just didn't work very well
before.  And it's not batching the commits better; it's reducing the
lock contention around realizing that the batched commit has happened.

 I updated the release docs to call the item group commit because I now
 don't see any reference to that term in our docs.

 I don't think I'd mention WAL writing at all, and just say that it
 improves the concurrency of locking around group commits.

+1.

-- 
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

Re: [HACKERS] Draft release notes complete

2012-05-10 Thread Heikki Linnakangas


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

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

2012-05-10 Thread Magnus Hagander

On Thu, May 10, 2012 at 5:11 AM, Bruce Momjian br...@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/

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

2012-05-10 Thread Thom Brown

On 10 May 2012 04:11, Bruce Momjian br...@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=guaibasaurusdt=lateststg=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


9.2_release_notes_typo_fixes.patch
Description: Binary data

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

Re: [HACKERS] Draft release notes complete




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

Bruce Momjianbr...@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

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

2012-05-10 Thread Magnus Hagander

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


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

 Bruce Momjianbr...@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/

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




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

On Thu, May 10, 2012 at 12:43 PM, Andrew Dunstanand...@dunslane.net  wrote:


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

Bruce Momjianbr...@momjian.uswrites:

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

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




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=guaibasaurusdt=lateststg=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


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

2012-05-10 Thread Peter Geoghegan

On 10 May 2012 04:11, Bruce Momjian br...@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

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




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

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

2012-05-10 Thread Simon Riggs

On 10 May 2012 13:11, Peter Geoghegan pe...@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

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

2012-05-10 Thread Vik Reykja

On Thu, May 10, 2012 at 2:24 PM, Andrew Dunstan and...@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.

Re: [HACKERS] Draft release notes complete

2012-05-10 Thread Heikki Linnakangas


On 10.05.2012 13:21, Thom Brown wrote:

On 10 May 2012 04:11, Bruce Momjianbr...@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

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