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" <[email protected]> To: "Dan Scales" <[email protected]> Cc: "Noah Misch" <[email protected]>, "Heikki Linnakangas" <[email protected]>, "Andres Freund" <[email protected]>, "Kevin Grittner" <[email protected]>, [email protected], [email protected], [email protected], [email protected], "Simon Riggs" <[email protected]> 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 <[email protected]> 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 -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
