Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

On 3/8/15 6:19 AM, Michael Paquier wrote:
> On Mon, Dec 2, 2013 at 7:07 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> On 2013-12-02 18:45:37 +0900, Michael Paquier wrote:
>>> On Mon, Dec 2, 2013 at 6:24 PM, Heikki Linnakangas
>>> <hlinnakangas(at)vmware(dot)com> wrote:
>>>> +1. The need for such a test suite has been mentioned every single time that
>>>> a bug or new feature related to replication, PITR or hot standby has come
>>>> up. So yes please! The only thing missing is someone to actually write the
>>>> thing. So if you have the time and energy, that'd be great!
>>
>>> I am sure you know who we need to convince in this case :)
>>
>> If you're alluding to Tom, I'd guess he doesn't need to be convinced of
>> such a facility in general. I seem to remember him complaining about the
>> lack of testing that as well.
>> Maybe that it shouldn't be part of the main regression schedule...
>>
>> +many from me as well. I think the big battle will be how to do it, not
>> if in general.
>
> (Reviving an old thread)
> So I am planning to seriously focus soon on this stuff, basically
> using the TAP tests as base infrastructure for this regression test
> suite. First, does using the TAP tests sound fine?
>
> On the top of my mind I got the following items that should be tested:
> - WAL replay: from archive, from stream
> - hot standby and read-only queries
> - node promotion
> - recovery targets and their interferences when multiple targets are
> specified (XID, name, timestamp, immediate)
> - timelines
> - recovery_target_action
> - recovery_min_apply_delay (check that WAL is fetch from a source at
> some correct interval, can use a special restore_command for that)
> - archive_cleanup_command (check that command is kicked at each restart point)
> - recovery_end_command (check that command is kicked at the end of recovery)
> - timeline jump of a standby after reconnecting to a promoted node

If we're keeping a list, there's also hot_standby_feedback,
max_standby_archive_delay and max_standby_streaming_delay.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com