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
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 |