I don't think that works anyways. No matter how thoroughly you update
all the hint bits there's still a chance someone else comes along and
sets one you missed or is setting hint bits on the same tuple at the
same time and your update gets lost.
greg
On 17 Oct 2008, at 06:59 PM, Alvaro Herrera
<alvherre@commandprompt.com> wrote:
> Simon Riggs wrote:
>>
>> On Fri, 2008-10-17 at 12:26 -0300, Alvaro Herrera wrote:
>>
>>> 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.
>>
>> Yes, it's clearly not acceptable bit by bit.
>>
>> But perhaps writing a single WAL record if you scan whole page and
>> set
>> all bits at once. Then it makes sense in some cases.
>
> Yeah, I thought about that too -- and perhaps give the scan some slop,
> so that it will also updates some more hint bits that would be updated
> in the next, say, 100 transactions. However this seems more messy
> than
> the other idea.
>
>> It might be possible to have a partial solution where some blocks
>> have
>> CRC checks, some not.
>
> That's another idea but it reduces the effectiveness of the check.
>
> --
> Alvaro Herrera http://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers