Re: Rewriting the test of pg_upgrade as a TAP test

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Noah Misch <noah(at)leadboat(dot)com>
Subject: Re: Rewriting the test of pg_upgrade as a TAP test
Date: 2017-04-04 13:52:17
Message-ID: 42d412a2-9cd7-7ee1-0c1a-e8d230d568b0@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2017-04-04 13:53:14 Re: Re: PATCH: pageinspect / add page_checksum and bt_page_items(bytea)
Previous Message Robert Haas 2017-04-04 13:45:26 Re: partitioned tables and contrib/sepgsql