Re: Rewriting the test of pg_upgrade as a TAP test - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Rewriting the test of pg_upgrade as a TAP test
Date
Msg-id 42d412a2-9cd7-7ee1-0c1a-e8d230d568b0@2ndquadrant.com
Whole thread Raw
In response to Re: Rewriting the test of pg_upgrade as a TAP test  (Andres Freund <andres@anarazel.de>)
Responses Re: Rewriting the test of pg_upgrade as a TAP test  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
On 4/3/17 11:32, Andres Freund wrote:
> That doesn't strike as particularly future proof.  We intentionally
> leave objects behind pg_regress runs, but that only works if we actually
> run them...

I generally agree with the sentiments expressed later in this thread.
But just to clarify what I meant here:  We don't need to run a, say,
1-minute serial test to load a few "left behind" objects for the
pg_upgrade test, if we can load the same set of objects using dedicated
scripting in say 2 seconds.  This would make both the pg_upgrade tests
faster and would reduce the hidden dependencies in the main tests about
which kinds of objects need to be left behind.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: partitioned tables and contrib/sepgsql
Next
From: David Steele
Date:
Subject: Re: Re: PATCH: pageinspect / add page_checksum andbt_page_items(bytea)