Re: segfault in hot standby for hash indexes - Mailing list pgsql-hackers

From Ashutosh Sharma
Subject Re: segfault in hot standby for hash indexes
Date
Msg-id CAE9k0P=PqX27CAaA67h2s9yxgmW19p5MBtmCrA92+zrqK8oV7A@mail.gmail.com
Whole thread Raw
In response to [HACKERS] segfault in hot standby for hash indexes  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
>> >>
>> >> I think it would have been probably okay to use *int* for ntuples as
>> >> that matches with what you are actually assigning in the function.
>> >
>> > okay, corrected it. Attached is newer version of patch.
>> >
>>
>> Thanks, this version looks good to me.
>
>
> It solves the problem for me.

Great..Thanks for confirming.

I'd like to test that I get the right answer
> on the standby, not just the absence of a crash, but I don't know how to do
> that effectively.  Has anyone used the new wal replay block consistency tool
> on hash indexes since this microvacuum code was committed?

Yes, I have used it for hash index but I used it after below commit,

commit 9abbf4727de746222ad8fc15b17348065389ae43
Author: Robert Haas <rhaas@postgresql.org>
Date:   Mon Mar 20 15:55:27 2017 -0400
   Another fix for single-page hash index vacuum.
   The WAL consistency checking code needed to be updated for the new   page status bit, but that didn't get done
previously.

All I did was set 'wal_consistency_checking = 'hash'' in
postgresql.conf and ran test cases on primary server. If there is any
inconsistent block on standby the tool would probably terminate the
recovery process and you would see following message in the server
logfile.

"inconsistent page found, rel %u/%u/%u, forknum %u, blkno %u"

--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: crashes due to setting max_parallel_workers=0
Next
From: Teodor Sigaev
Date:
Subject: Re: Potential data loss of 2PC files