Re: segfault in hot standby for hash indexes

Поиск
Список
Период
Сортировка
От Ashutosh Sharma
Тема Re: segfault in hot standby for hash indexes
Дата
Msg-id CAE9k0P=PqX27CAaA67h2s9yxgmW19p5MBtmCrA92+zrqK8oV7A@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] segfault in hot standby for hash indexes  (Jeff Janes <jeff.janes@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: crashes due to setting max_parallel_workers=0
Следующее
От: Teodor Sigaev
Дата:
Сообщение: Re: Potential data loss of 2PC files