Re: [HACKERS] Setting pd_lower in GIN metapage - Mailing list pgsql-hackers

From Amit Langote
Subject Re: [HACKERS] Setting pd_lower in GIN metapage
Date
Msg-id 05607ea3-e028-b57b-e0ff-8efd9cda14a0@lab.ntt.co.jp
Whole thread Raw
In response to Re: [HACKERS] Setting pd_lower in GIN metapage  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] Setting pd_lower in GIN metapage  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On 2017/06/23 15:07, Michael Paquier wrote:
> On Fri, Jun 23, 2017 at 2:56 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>> Thank you for updating the patch. It looks good to me.
>> BTW I'm inclined to have a regression test case where doing 'make
>> check' to the streaming replication environment with
>> wal_consistency_check on standby server so that we can detect a bug
>> around the wal.
> 
> This would be very costly. A single run of the main regression tests
> generates 15 to 20GB of FPWs if I recall correctly. Tiny buildfarm
> members would suffer on that. *cough*

Initially, I had naively set wal_consistency_check = all before running
make installcheck and then had to wait for a long time to confirm that WAL
generated by the gin test indeed caused consistency check failure on the
standby with the v1 patch.

But I can see Sawada-san's point that there should be some way for
developers writing code that better had gone through WAL consistency
checking facility to do it without much hassle.  But then again, it may
not be that frequent to need that.

Thanks,
Amit




pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Setting pd_lower in GIN metapage
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Broken O(n^2) avoidance in wal segment recycling.