From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Kuntal Ghosh <kuntalghosh(dot)2007(at)gmail(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-08-27 12:58:23 |
Message-ID: | CAB7nPqSJGWMzxh=9tr6MeN2L6PnpP5oSCyK06ZjnjDc8N_uMMw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Aug 27, 2016 at 6:16 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On 27 August 2016 at 07:36, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>> On Fri, Aug 26, 2016 at 9:26 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>>>
>>> I think you should add this as part of the default testing for both
>>> check and installcheck. I can't imagine why we'd have it and not use
>>> it during testing.
>>>
>>
>> The actual consistency checks are done during redo (replay), so not
>> sure whats in you mind for enabling it with check or installcheck. I
>> think we can run few recovery/replay tests with this framework. Also
>> running the tests under this framework could be time-consuming as it
>> logs the entire page for each WAL record we write and then during
>> replay reads the same.
>
> I'd like to see an automated test added so we can be certain we don't
> add things that break recovery. Don't mind much where or how.
>
> The main use is to maintain that certainty while in production.
For developers, having extra checks with the new routines in WAL_DEBUG
could also be useful for a code path producing WAL. Let's not forget
that as well.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-08-27 13:24:11 | Re: Missing checks when malloc returns NULL... |
Previous Message | Kuntal Ghosh | 2016-08-27 11:09:21 | Re: WAL consistency check facility |