On 3/8/15 6:19 AM, Michael Paquier wrote:
On Mon, Dec 2, 2013 at 7:07 PM, Andres Freund <and...@2ndquadrant.com> wrote:
On 2013-12-02 18:45:37 +0900, Michael Paquier wrote:
On Mon, Dec 2, 2013 at 6:24 PM, Heikki Linnakangas
<hlinnakan...@vmware.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
