Horton

Re: Draft release notes complete

Andrew Dunstan <andrew@dunslane.net>

View thread
From: Andrew Dunstan <andrew@dunslane.net>
To: Magnus Hagander <magnus@hagander.net>
Cc: Peter Eisentraut <peter_e@gmx.net>, Bruce Momjian <bruce@momjian.us>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2012-05-11T15:44:49Z
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


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