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

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

Regards,
--
Michael