Re: Write Ahead Logging for Hash Indexes

On Thu, Sep 15, 2016 at 11:42 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:

>
> Okay, Thanks for pointing out the same. I have fixed it. Apart from
> that, I have changed _hash_alloc_buckets() to initialize the page
> instead of making it completely Zero because of problems discussed in
> another related thread [1]. I have also updated README.
>
>
with v7 of the concurrent has patch and v4 of the write ahead log patch and
the latest relcache patch (I don't know how important that is to
reproducing this, I suspect it is not), I once got this error:

38422 00000 2016-09-19 16:25:50.055 PDT:LOG: database system was
interrupted; last known up at 2016-09-19 16:25:49 PDT
38422 00000 2016-09-19 16:25:50.057 PDT:LOG: database system was not
properly shut down; automatic recovery in progress
38422 00000 2016-09-19 16:25:50.057 PDT:LOG: redo starts at 3F/2200DE90
38422 01000 2016-09-19 16:25:50.061 PDT:WARNING: page verification
failed, calculated checksum 65067 but expected 21260
38422 01000 2016-09-19 16:25:50.061 PDT:CONTEXT: xlog redo at 3F/22053B50
for Hash/ADD_OVFL_PAGE: bmsize 4096, bmpage_found T
38422 XX001 2016-09-19 16:25:50.071 PDT:FATAL: invalid page in block 9 of
relation base/16384/17334
38422 XX001 2016-09-19 16:25:50.071 PDT:CONTEXT: xlog redo at 3F/22053B50
for Hash/ADD_OVFL_PAGE: bmsize 4096, bmpage_found T

The original page with the invalid checksum is:

$ od 16384_17334_9
0000000 000032 000000 015420 077347 020404 000000 000030 017760
0000020 017760 020004 000000 000000 000000 000000 000000 000000
0000040 000000 000000 000000 000000 000000 000000 000000 000000
*
0017760 000007 000002 177777 177777 000007 000000 000002 177600
0020000

If I ignore the checksum failure and re-start the system, the page gets
restored to be a bitmap page.

Cheers,

Jeff