Horton

Re: 16-bit page checksums for 9.2

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Simon Riggs <simon@2ndquadrant.com>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, david@fetter.org, aidan@highrise.ca, stark@mit.edu, pgsql-hackers@postgresql.org
Date: 2012-01-06T19:49:52Z
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 Fri, Jan 6, 2012 at 2:35 PM, Andres Freund <andres@anarazel.de> wrote:
> On Friday, January 06, 2012 07:26:14 PM Simon Riggs wrote:
>> The following patch (v4) introduces a new WAL record type that writes
>> backup blocks for the first hint on a block in any checkpoint that has
>> not previously been changed. IMHO this fixes the torn page problem
>> correctly, though at some additional loss of performance but not the
>> total catastrophe some people had imagined. Specifically we don't need
>> to log anywhere near 100% of hint bit settings, much more like 20-30%
>> (estimated not measured).
> Well, but it will hurt in those cases where hint bits already hurt hugely.
> Which is for example when accessing huge amounts of data the first time after
> loading it. Which is not exactly uncommon...

No, but I'd rather see us commit a checksum patch that sometimes
carries a major performance penalty and then work to reduce that
penalty later than never commit anything at all.  I think it's
unrealistic to assume we're going to get this perfectly right in one
try.  I am not sure whether this particular patch is close enough for
government work or still needs more hacking, and it may well be the
latter, but there is no use holding our breath and waiting for
absolute perfection.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company