Re: WAL consistency check facility

On Thu, Sep 1, 2016 at 8:30 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Thu, Sep 1, 2016 at 11:32 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>> On Wed, Aug 31, 2016 at 7:02 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>>> On 27 August 2016 at 12:09, Kuntal Ghosh <kuntalghosh.2007@gmail.com> wrote:
>>>
>>>>>> * wal_consistency_mask = 511  /* Enable consistency check mask bit*/
>>>>>
>>>>> What does this mean? (No docs)
>>>>
>>>> I was using this parameter as a masking integer to indicate the
>>>> operations(rmgr list) for which we need this feature to be enabled.
>>>> Since, this could be confusing, I've changed it accordingly so that it
>>>> accepts a list of rmgrIDs. (suggested by Michael, Amit and Robert)
>>>
>>> Why would we want that?
>>
>> It would be easier to test and develop the various modules separately.
>> As an example, if we develop a new AM which needs WAL facility or
>> adding WAL capability to an existing system (say Hash Index), we can
>> just test that module, rather than whole system.  I think it can help
>> us in narrowing down the problem, if we have facility to enable it at
>> RMGR ID level.  Having said that, I think this must have the facility
>> to enable it for all the RMGR ID's (say ALL) and probably that should
>> be default.
>
> As far as I am understanding things, we are aiming at something that
> could be used on production systems.
>

I don't think you can enable it by default in production systems.
Enabling it will lead to significant performance drop as it writes the
whole page after each record for most type of RMGR ID's.

> And, honestly, any people
> enabling it would just do it for all RMGRs because that's a
> no-brainer.

Agreed, but remember enabling it for all is not free.

> If we are designing something for testing purposes
> instead, something is wrong with this patch then.
>

What is wrong?

> Doing filtering at RMGR level for testing and development purposes
> will be done by somebody who has the skills to filter out which
> records he should look at.
>

Right, but in that way, if you see many of our guc parameters needs a
good level of understanding to set the correct  values for them.  For
example, do you think it is easy for user to set value for
"replacement_sort_tuples" without reading the description or
understanding the meaning of same.  This example might not be the best
example, but I think there are other parameters which do require some
deeper understanding of system.  The main thing is default values for
such parameters should be chosen carefully such that it represents
most common usage.

> Or he'll bump into an existing bump. So I'd
> rather keep this thing simple.
>

It seems to me that having an option of 'ALL' would make it easier for
users to set it.


-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com