Re: 16-bit page checksums for 9.2
Simon Riggs <simon@2ndquadrant.com>
From: Simon Riggs <simon@2ndQuadrant.com>
To: Dan Scales <scales@vmware.com>
Cc: Robert Haas <robertmhaas@gmail.com>, 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
Date: 2012-01-28T13:49:02Z
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 →
-
Wakeup WALWriter as needed for asynchronous commit performance.
- 4de82f7d7c50 9.2.0 cited
On Fri, Jan 27, 2012 at 9:07 PM, Dan Scales <scales@vmware.com> wrote: > 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) I'll have another look at that. Seems like we can make it various ways, we just need to decide the code placement. > 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. You don't need to checksum the extend because no data is written at that point. It create a new block that will become dirty at some point and then be written out, which will trigger the checksum. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services