On Thu, Dec 15, 2011 at 6:50 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote:
>> unless you are proposing to remove >> the prev_link from the scope of the CRC, which is not exactly a >> penalty-free change. > > > We could CRC the rest of the record header before getting the lock, though, > and only include the prev-link while holding the lock. I micro-benchmarked > that a little bit, but didn't see much benefit from doing just that. Once > you do more drastic changes so that the lock doesn't need to be held while > copying the data and calculating the CRC of the record header, so that those > things can be done in parallel, it matters even less. You missed your cue to discuss leaving the prev link out of the CRC altogether. On its own that sounds dangerous, but its not. When we need to confirm the prev link we already know what we expect it to be, so CRC-ing it is overkill. That isn't true of any other part of the WAL record, so the prev link is the only thing we can relax, but thats OK because we can CRC check everything else outside of the locked section. That isn't my idea, but I'm happy to put it on the table since I'm not shy. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
