TAP / recovery-test fs-level backups, psql enhancements etc

From: Craig Ringer <craig(at)2ndquadrant(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Álvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Subject: TAP / recovery-test fs-level backups, psql enhancements etc
Date: 2016-03-01 13:48:56
Message-ID: CAMsr+YEc2Ek=qJFJ2JeV7Spz69pOduoUJXBowZMppVYdeieRdA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all

I've been working with the new TAP tests for recovery and have a number of
enhancements I'd like to make to the tooling to make writing tests easier
and nicer. I've also included two improvements proposed by Kyotaro
HORIGUCHI in the prior thread about the now-committed TAP recovery tests.

I developed these changes as part of testing failover slots and logical
decoding timeline following, where I found a need for better control over
psql, the ability to make filesystem level backups, etc. It doesn't make
sense to try to jam all that into my test script when it belongs in the
infrastructure.

Patches attached, each explains what it does and what for.

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
0001-Allow-multiple-temp-config-arguments-to-pg_regress.patch text/x-patch 1.7 KB
0002-TAP-Add-filtering-to-RecursiveCopy.patch text/x-patch 3.0 KB
0003-TAP-Add-easier-more-flexible-ways-to-invoke-psql.patch text/x-patch 9.6 KB
0004-TAP-Add-support-for-taking-filesystem-level-backups.patch text/x-patch 3.2 KB
0005-TAP-Suffix-temporary-directories-with-node-name.patch text/x-patch 1.3 KB
0006-TAP-Retain-tempdirs-for-failed-tests.patch text/x-patch 850 bytes
0007-TAP-Perltidy-PostgresNode.pm.patch text/x-patch 12.8 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2016-03-01 13:53:10 Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
Previous Message Jim Nasby 2016-03-01 13:36:45 Re: dealing with extension dependencies that aren't quite 'e'