Horton

Re: Draft release notes complete

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Peter Geoghegan <peter@2ndquadrant.com>, Jeff Janes <jeff.janes@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2012-05-14T16:24:03Z
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 May 14, 2012, at 9:06 AM, Bruce Momjian <bruce@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