Horton

Re: 16-bit page checksums for 9.2

Dan Scales <scales@vmware.com>

View thread
From: Dan Scales <scales@vmware.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Noah Misch <noah@leadboat.com>, Heikki Linnakangas <heikki.linnakangas@enterprisedb.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, Simon Riggs <simon@2ndquadrant.com>
Date: 2012-01-27T21:07:00Z
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.

The advantage of putting the checksum calculation in smgrwrite() (or mdwrite()) is that it catches a bunch of page writes that don't go through the buffer pool (see calls to smgrwrite() in nbtree.c, nbtsort.c, spginsert.c)

Also, I missed this before:  don't you want to add the checksum calculation (PageSetVerificationInfo) to mdextend() (or preferably smgrextend()) as well?  Otherwise, you won't be checksumming a bunch of the new pages.

Dan

----- Original Message -----
From: "Robert Haas" <robertmhaas@gmail.com>
To: "Dan Scales" <scales@vmware.com>
Cc: "Noah Misch" <noah@leadboat.com>, "Heikki Linnakangas" <heikki.linnakangas@enterprisedb.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, "Simon Riggs" <simon@2ndquadrant.com>
Sent: Friday, January 27, 2012 5:19:32 AM
Subject: Re: [HACKERS] 16-bit page checksums for 9.2

On Thu, Jan 26, 2012 at 7:01 PM, Dan Scales <scales@vmware.com> wrote:
> I'm not sure why you moved the checksum calculation (PageSetVerificationInfo) to mdwrite() rather than smgrwrite().  If there were every another storage backend, it would have to duplicate the checksum check, right?  Is there a disadvantage to putting it in smgrwrite()?

The smgr and md layers don't currently know anything about the page
format, and I imagine we want to keep it that way.  It seems like the
right place for this is in some higher layer, like bufmgr.

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