On Thu, Jun 14, 2012 at 10:01 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > This has the advantage that you can calculate the CRC for all the other > fields before acquiring WALInsertLock. For xl_prev, you need to know where > exactly the record is inserted, so it's handy that it's the last field > before CRC.
It may be late to mention this but fwiw you don't need to reorder the fields to do this. CRC has the property that you can easily adjust it for any changes to the data covered by it. Regardless of where the xl_prev link is you can calculate the CRC as if xl_prev is 0 and then once you get the lock "add in" the correct xl_prev. This is an argument in favour of using CRC over other checksums for which that would be hard or impossible. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
