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.
----- Original Message -----
From: "Robert Haas" <robertmhaas(at)gmail(dot)com>
To: "Dan Scales" <scales(at)vmware(dot)com>
Cc: "Noah Misch" <noah(at)leadboat(dot)com>, "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Andres Freund" <andres(at)anarazel(dot)de>, "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>, david(at)fetter(dot)org, aidan(at)highrise(dot)ca, stark(at)mit(dot)edu, pgsql-hackers(at)postgresql(dot)org, "Simon Riggs" <simon(at)2ndquadrant(dot)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(at)vmware(dot)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.
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Jeff Janes||Date: 2012-01-27 21:45:16|
|Subject: Re: Simulating Clog Contention|
|Previous:||From: Peter Geoghegan||Date: 2012-01-27 20:33:56|
|Subject: Re: Progress on fast path sorting, btree index creation time|