Re: Write Ahead Logging for Hash Indexes

On Thu, Sep 22, 2016 at 10:16 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Thu, Sep 22, 2016 at 8:51 AM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>>
>>
>> Correct. But any torn page write must be covered by the restoration of a
>> full page image during replay, shouldn't it? And that restoration should
>> happen blindly, without first reading in the old page and verifying the
>> checksum.
>>
>
> Probably, but I think this is not currently the way it is handled and
> I don't want to change it. AFAIU, what happens now is that we first
> read the old page (and we do page verification while reading old page
> and display *warning* if checksum doesn't match) and then restore the
> image. The relevant code path is
> XLogReadBufferForRedo()->XLogReadBufferExtended()->ReadBufferWithoutRelcache()->ReadBuffer_common()->PageIsVerified().
>
> Now, here the point is that why instead of WARNING we are seeing FATAL
> for the bitmap page of hash index. The reason as explained in my
> previous e-mail is that for bitmap page we are not logging full page
> image and we should fix that as explained there. Once the full page
> image is logged, then first time it reads the torn page, it will use
> flag RBM_ZERO_AND_LOCK which will make the FATAL error you are seeing
> to WARNING.
>

I think here I am slightly wrong. For the full page writes, it do use
RBM_ZERO_AND_LOCK mode to read the page and for such mode we are not
doing page verification check and rather blindly setting the page to
zero and then overwrites it with full page image. So after my fix,
you will not see the error of checksum failure. I have a fix ready,
but still doing some more verification. If everything passes, I will
share the patch in a day or so.

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com