Re: WAL format changes

From: Greg Stark <stark(at)mit(dot)edu>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WAL format changes
Date: 2012-07-06 21:24:12
Message-ID: CAM-w4HMe_Ty-6bbqE_3A55q8M5OnjdPrqQJXBW51tM6nOi9L9A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 14, 2012 at 10:01 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2012-07-06 21:46:03 Re: transforms
Previous Message Jan Urbański 2012-07-06 21:12:44 Re: Re: [COMMITTERS] pgsql: Fix mapping of PostgreSQL encodings to Python encodings.