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 <[EMAIL PROTECTED]> wrote:
Martijn van Oosterhout <[EMAIL PROTECTED]> 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
