I think double buffering solves the torn page problem but not the lack
of wal logging. Alvarro solved the wal logging by deferring the wal
logs. But I'm not sure how confident we are that it's logging enough.
I'm beginning to think just excluding the hint bits would be simpler
and safer. If we're double buffering then it might be possible to do
that pretty cheaply. Copy the whole buffer with memcpy then loop
through the line pointers unsetting the hint bits. Then do the crc.
Though that would prevent us from doing "zero-copy" crc by doing it in
the copy.
greg
On 9 Nov 2008, at 04:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Martijn van Oosterhout <kleptog@svana.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
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers