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

From Stephen Frost
Subject Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test
Date
Msg-id 20170414110309.GV9812@tamriel.snowman.net
Whole thread Raw
In response to Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test  (Michael Paquier <michael.paquier@gmail.com>)
List pgsql-hackers
Michael,

* Michael Paquier (michael.paquier@gmail.com) wrote:
> On Thu, Apr 6, 2017 at 7:48 AM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
> > On Wed, Apr 5, 2017 at 10:24 PM, Stephen Frost <sfrost@snowman.net> wrote:
> >> * Michael Paquier (michael.paquier@gmail.com) wrote:
> >>> 1) Initialize the old cluster and start it.
> >>> 2) create a bunch of databases with full range of ascii characters.
> >>> 3) Run regression tests.
> >>> 4) Take dump on old cluster.
> >>> 4) Stop the old cluster.
> >>> 5) Initialize the new cluster.
> >>> 6) Run pg_upgrade.
> >>> 7) Start new cluster.
> >>> 8) Take dump from it.
> >>> 9) Run deletion script (Oops forgot this part!)
> >>
> >> Presumably the check to match the old dump against the new one is also
> >> performed?
> >
> > Yes. That's run with command_ok() at the end.
>
> Attached is an updated patch to use --no-sync with pg_dumpall calls.

Some of those were specifically left around to test those code paths.
I'm not sure if these were those or not though, Andrew was the one who
reviewed the various pg_dumpall calls to add --no-sync in places.

Thanks!

Stephen

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: [HACKERS] Logical replication launcher uses wal_retrieve_retry_interval
Next
From: Craig Ringer
Date:
Subject: Re: [HACKERS] Letting the client choose the protocol to use during aSASL exchange