Horton

Re: Draft release notes complete

Stephen Frost <sfrost@snowman.net>

View thread
From: Stephen Frost <sfrost@snowman.net>
To: Bruce Momjian <bruce@momjian.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, Alvaro Herrera <alvherre@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Peter Eisentraut <peter_e@gmx.net>, Magnus Hagander <magnus@hagander.net>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2012-09-06T01:59:50Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Expose track_iotiming information via pg_stat_statements.

  2. Rewrite GiST support code for rangetypes.

  3. Clean up a couple of box gist helper functions.

  4. Replace the "New Linear" GiST split algorithm for boxes and points with a

* Bruce Momjian (bruce@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