From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Block-level CRC checks |
Date: | 2008-11-09 16:02:32 |
Message-ID: | 17269.1226246552@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
> There is another option I havn't seen mentioned anywhere yet: a single
> bit change in a page has a predictable change on the CRC, dependant
> only on the position of the bit. So in theory it would be possible for
> the process changing the hint bit to update the CRC with a single XOR
> operation. Working out what to XOR it with is the hard part.
> Although, maybe locking of the hint bits would be a problem?
Yes it would :-(. Also, this scheme would point us towards maintaining
the CRCs *continually* while the page is in memory, rather than only
recalculating them upon write. So every tuple insert/update/delete
would require a recalculation of the entire page CRC.
What happened to the plan to double-buffer the writes to avoid this
issue?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2008-11-09 16:54:38 | Re: Spurious Kerberos error messages |
Previous Message | Ron Mayer | 2008-11-09 15:36:03 | Re: Patch for SQL-Standard Interval output and decoupling DateStyle from IntervalStyle |