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" <robertmh...@gmail.com> To: "Dan Scales" <sca...@vmware.com> Cc: "Noah Misch" <n...@leadboat.com>, "Heikki Linnakangas" <heikki.linnakan...@enterprisedb.com>, "Andres Freund" <and...@anarazel.de>, "Kevin Grittner" <kevin.gritt...@wicourts.gov>, da...@fetter.org, ai...@highrise.ca, st...@mit.edu, pgsql-hackers@postgresql.org, "Simon Riggs" <si...@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 <sca...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
