Horton

Re: Draft release notes complete

Peter Eisentraut <peter_e@gmx.net>

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