Re: In-core regression tests for replication, cascading, archiving, PITR, etc. - Mailing list pgsql-hackers

From Noah Misch
Subject Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
Date
Msg-id 20150311054725.GB294547@tornado.leadboat.com
Whole thread Raw
In response to Re: In-core regression tests for replication, cascading, archiving, PITR, etc.  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
List pgsql-hackers
On Sun, Mar 08, 2015 at 08:19:39PM +0900, Michael Paquier wrote:
> 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?

Yes.

> 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

Those sound good.  The TAP suites still lack support for any Windows target.
If you're inclined to fix that, it would be a great contribution.  The more we
accrue tests before doing that, the harder it will be to dig out.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: moving from contrib to bin
Next
From: Pavel Stehule
Date:
Subject: Re: Rethinking the parameter access hooks for plpgsql's benefit