Horton

Re: 16-bit page checksums for 9.2

Jeff Davis <pgsql@j-davis.com>

View thread
From: Jeff Davis <pgsql@j-davis.com>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Noah Misch <noah@leadboat.com>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>, Andres Freund <andres@anarazel.de>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, david@fetter.org, aidan@highrise.ca, stark@mit.edu, pgsql-hackers@postgresql.org
Date: 2012-08-10T23:16:43Z
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. Wakeup WALWriter as needed for asynchronous commit performance.

On Sun, 2012-02-19 at 21:49 +0000, Simon Riggs wrote:
> On Thu, Feb 16, 2012 at 11:16 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> 
> > v8 attached
> 
> v10 attached.
> 
> This patch covers all the valid concerns discussed and has been
> extensively tested.

Is there something I can do to help get this ready for the next
commitfest? I am willing to rebase it, but I was worried that might
cause confusion. I am also willing to review it after the rebase, of
course.

There are still a couple open issues, including:

* Store the checksum in the page version field or the TLI field?

* What mechanism to guarantee to the user that all pages are properly
protected by checksums (rather than just new pages)? In other words,
there are more than the two states represented by the GUC.

* What specific data is included in the checksum? I suggested that we
include the block number, and maybe the OID.

Regards,
	Jeff Davis