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"
<jonah.harris@gmail.com> wrote:
> On Fri, Oct 17, 2008 at 11:26 AM, Alvaro Herrera
> <alvherre@commandprompt.com> 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