Re: WAL consistency check facility

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Amit Kapila <amit(dot)kapila(at)enterprisedb(dot)com>
Subject: Re: WAL consistency check facility
Date: 2016-11-02 03:03:52
Message-ID: CAM3SWZRtaM2kcEdM0WFEvvzLAY1=bsg2yxdLfAQNq7=4dopFrA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Oct 31, 2016 at 5:31 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Oct 28, 2016 at 2:05 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
>> And here we go. Here is a review as well as a large brush-up for this
>> patch. A couple of things:
>> - wal_consistency is using a list of RMGRs, at the cost of being
>> PGC_POSTMASTER. I'd suggest making it PGC_SUSER, and use a boolean (I
>> have been thinking hard about that, and still I don't see the point).
>> It is rather easy to for example default it to false, and enable it to
>> true to check if a certain code path is correctly exercised or not for
>> WAL consistency. Note that this simplification reduces the patch size
>> by 100~150 lines. I know, I know, I'd expect some complains about
>> that....
>
> I don't understand how you can fail to see the point of that. As you
> yourself said, this facility generates a ton of WAL. If you're
> focusing on one AM, why would you want to be forced to incur the
> overhead for every other AM? A good deal has been written about this
> upthread already, and just saying "I don't see the point" seems to be
> ignoring the explanations already given.

+1. I strongly agree.

--
Peter Geoghegan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2016-11-02 03:31:16 Re: Speed up Clog Access by increasing CLOG buffers
Previous Message Amit Langote 2016-11-02 02:55:51 Re: Declarative partitioning - another take