On Thu, Sep 15, 2016 at 11:42 PM, Amit Kapila <amit.kapil...@gmail.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
