I'm far from convinced wal logging hint bits is a non starter. In fact
I doubt the wal log itself I a problem. Having to take the buffer lock
does suck though.
Heikki had a clever idea earlier which was to have two crc checks- one
which skips the hint bits and one dedicated to hint bits. If the
second doesn't match we clear all the hint bits.
The problem with that is that skipping the hint bits for the main crc
would slow it down severely. It would make a lot of sense if the hint
bits were all in a contiguous block of memory but I can't see how to
make that add up.
greg
On 17 Oct 2008, at 05:42 PM, "Jonah H. Harris"
<[EMAIL PROTECTED]> wrote:
On Fri, Oct 17, 2008 at 11:26 AM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
So this discussion died with no solution arising to the
hint-bit-setting-invalidates-the-CRC problem.
I've been busy.
Apparently the only solution in sight is to WAL-log hint bits. Simon
opines it would be horrible from a performance standpoint to WAL-log
every hint bit set, and I think we all agree with that. So we need
to
find an alternative mechanism to WAL log hint bits.
Agreed.
I thought about causing a process that's about to write a page
check a
flag that says "this page has been dirtied by someone who didn't
bother
to generate WAL". If the flag is set, then the writer process is
forced
to write a WAL record containing all hint bits in the page, and only
then it is allowed to write the page (and thus calculate the new
CRC).
Interesting idea... let me ponder it for a bit.
--
Jonah H. Harris, Senior DBA
myYearbook.com
--
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
