Re: WAL consistency check facility
От | Michael Paquier |
---|---|
Тема | Re: WAL consistency check facility |
Дата | |
Msg-id | CAB7nPqQsf5oQDFJrW55wOuU_mXbD=y=6Y4C6Vy3=ttR2YjE9Uw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: WAL consistency check facility (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: WAL consistency check facility
|
Список | pgsql-hackers |
On Mon, Oct 31, 2016 at 9:31 PM, Robert Haas <robertmhaas@gmail.com> wrote: > On Fri, Oct 28, 2016 at 2:05 AM, Michael Paquier > <michael.paquier@gmail.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. Hehe, I was expecting you to jump on those lines. While looking at the patch I have simplified it first to focus on the core engine of the thing. Adding back this code sounds fine to me as there is a wall of contestation. I offer to do it myself if the effort is the problem. -- Michael
В списке pgsql-hackers по дате отправления: