Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On 9/22/17 16:48, Peter Eisentraut wrote: > On 9/19/17 19:00, Michael Paquier wrote: >> On Wed, Sep 20, 2017 at 7:57 AM, Peter Eisentraut >> wrote: >>> To get things rolling, I have committed just the basic TAP tests, to >>> give it a spin on the build farm.

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On 9/19/17 19:00, Michael Paquier wrote: > On Wed, Sep 20, 2017 at 7:57 AM, Peter Eisentraut > wrote: >> To get things rolling, I have committed just the basic TAP tests, to >> give it a spin on the build farm. I'll work through the rest in the >> coming days.

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On Wed, Sep 20, 2017 at 7:57 AM, Peter Eisentraut wrote: > To get things rolling, I have committed just the basic TAP tests, to > give it a spin on the build farm. I'll work through the rest in the > coming days. Thanks! -- Michael -- Sent via pgsql-hackers

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On 9/19/17 07:37, Michael Paquier wrote: >>> This patch is logged as "waiting on author" in the current commit >>> fest, but any new patch will depend on the feedback that any other >>> hacker has to offer based on the set of ideas I have posted upthread. >>> Hence I am yet unsure what is the

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On Tue, Sep 19, 2017 at 6:15 PM, Alvaro Herrera wrote: > Michael Paquier wrote: >> On Thu, Sep 7, 2017 at 11:14 AM, Michael Paquier >> wrote: >> > Or we could make upgradecheck a noop, then remove it once all the MSVC >> > animals have upgraded

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

Michael Paquier wrote: > On Thu, Sep 7, 2017 at 11:14 AM, Michael Paquier > wrote: > > Or we could make upgradecheck a noop, then remove it once all the MSVC > > animals have upgraded to a newer version of the buildfarm client which > > does not use upgradecheck anymore

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On Thu, Sep 7, 2017 at 11:14 AM, Michael Paquier wrote: > Or we could make upgradecheck a noop, then remove it once all the MSVC > animals have upgraded to a newer version of the buildfarm client which > does not use upgradecheck anymore (I am fine to send a patch or a

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On Wed, Sep 6, 2017 at 10:05 PM, Peter Eisentraut wrote: > Please send a rebased patch. > > I propose splitting the single Perl script into three separate test > files: one for basic command-line option handling and so on (I would > like to expand that later),

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On Wed, Sep 6, 2017 at 11:44 PM, Tom Lane wrote: > Alvaro Herrera writes: >> Peter Eisentraut wrote: >>> We also need to have a plan for handling the build farm. Maybe keep the >>> vcregress.pl upgradecheck target as a thin wrapper for the time

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

Alvaro Herrera writes: > Peter Eisentraut wrote: >> We also need to have a plan for handling the build farm. Maybe keep the >> vcregress.pl upgradecheck target as a thin wrapper for the time being? > The buildfarm already runs "make check" in src/bin/ when TAP tests are

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

Peter Eisentraut wrote: > I propose splitting the single Perl script into three separate test > files: one for basic command-line option handling and so on (I would > like to expand that later), one for the main upgrade test, and one for > the funny database names tests. Check. > We also need

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On 4/14/17 02:00, Michael Paquier wrote: > Attached is an updated patch to use --no-sync with pg_dumpall calls. Please send a rebased patch. I propose splitting the single Perl script into three separate test files: one for basic command-line option handling and so on (I would like to expand

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

* Michael Paquier (michael.paqu...@gmail.com) wrote: > On Fri, Apr 14, 2017 at 8:03 PM, Stephen Frost wrote: > > 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

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On Fri, Apr 14, 2017 at 8:03 PM, Stephen Frost wrote: > 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. Well,

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Thu, Apr 6, 2017 at 7:48 AM, Michael Paquier > wrote: > > On Wed, Apr 5, 2017 at 10:24 PM, Stephen Frost wrote: > >> * Michael Paquier (michael.paqu...@gmail.com) wrote: > >>> 1)

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On Thu, Apr 6, 2017 at 7:48 AM, Michael Paquier wrote: > On Wed, Apr 5, 2017 at 10:24 PM, Stephen Frost wrote: >> * Michael Paquier (michael.paqu...@gmail.com) wrote: >>> 1) Initialize the old cluster and start it. >>> 2) create a bunch of databases

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On Wed, Apr 05, 2017 at 11:13:33AM -0400, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Stephen Frost writes: > > > I'm all for adding tests into pg_dump which do things like drop columns > > > and change column names and other cases which could impact if

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On Wed, Apr 5, 2017 at 10:24 PM, Stephen Frost wrote: > * Michael Paquier (michael.paqu...@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

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > I'm all for adding tests into pg_dump which do things like drop columns > > and change column names and other cases which could impact if the > > pg_dump is correct or not, and there's nothing preventing

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

Andres, * Andres Freund (and...@anarazel.de) wrote: > On 2017-04-05 10:50:19 -0400, Stephen Frost wrote: > > Probably because the point was brought up that the regression tests for > > pg_upgrade spend a bunch of time doing something which, ultimately, > > don't actually add any real value. Yes,

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

Stephen Frost writes: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> Right. But there's a certain amount of serendipity involved in using the >> core regression tests' final results. For example, I don't know how long >> it would've taken us to understand the problems around

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On 2017-04-05 10:50:19 -0400, Stephen Frost wrote: > Andres, > > * Andres Freund (and...@anarazel.de) wrote: > > On 2017-04-05 10:40:41 -0400, Stephen Frost wrote: > > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > > > Stephen Frost writes: > > > > > I believe that what Peter

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

Andres, * Andres Freund (and...@anarazel.de) wrote: > On 2017-04-05 10:40:41 -0400, Stephen Frost wrote: > > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > > Stephen Frost writes: > > > > I believe that what Peter was getting at is that the pg_dump TAP tests > > > > create a

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

Hi, On 2017-04-05 10:40:41 -0400, Stephen Frost wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: > > Stephen Frost writes: > > > I believe that what Peter was getting at is that the pg_dump TAP tests > > > create a whole slew of objects in just a few seconds and are able to >

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

Tom, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > I believe that what Peter was getting at is that the pg_dump TAP tests > > create a whole slew of objects in just a few seconds and are able to > > then exercise those code-paths in pg_dump, without

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

Stephen Frost writes: > I believe that what Peter was getting at is that the pg_dump TAP tests > create a whole slew of objects in just a few seconds and are able to > then exercise those code-paths in pg_dump, without needing to run the > entire serial regression test run.

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Tue, Apr 4, 2017 at 10:52 PM, Peter Eisentraut > wrote: > > On 4/3/17 11:32, Andres Freund wrote: > >> That doesn't strike as particularly future proof. We intentionally > >> leave objects

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

Michael, * Michael Paquier (michael.paqu...@gmail.com) wrote: > On Tue, Apr 4, 2017 at 9:30 PM, Stephen Frost wrote: > > * Michael Paquier (michael.paqu...@gmail.com) wrote: > >> On Tue, Apr 4, 2017 at 7:38 AM, Stephen Frost wrote: > >> The patch

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On Tue, Apr 4, 2017 at 10:52 PM, Peter Eisentraut wrote: > 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... > >

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On Tue, Apr 4, 2017 at 9:30 PM, Stephen Frost wrote: > * Michael Paquier (michael.paqu...@gmail.com) wrote: >> On Tue, Apr 4, 2017 at 7:38 AM, Stephen Frost wrote: >> The patch presented here does lower the coverage we have now. > > I assume (perhaps

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

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

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

* Michael Paquier (michael.paqu...@gmail.com) wrote: > On Tue, Apr 4, 2017 at 7:38 AM, Stephen Frost wrote: > > Not good if it lowers the coverage, but hopefully that's fixable. Have you > > analyzed where we're reducing coverage..? > > The current set of tests is just

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On Tue, Apr 4, 2017 at 7:38 AM, Stephen Frost wrote: > Not good if it lowers the coverage, but hopefully that's fixable. Have you > analyzed where we're reducing coverage..? The current set of tests is just running pg_upgrade using the same version for the source and target

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

Michael, On Mon, Apr 3, 2017 at 18:29 Michael Paquier wrote: > On Tue, Apr 4, 2017 at 12:12 AM, Stephen Frost wrote: > > I'm very curious what you're thinking here? IIRC, Andrew had some ideas > > for how to do true cross-version testing with TAP

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On Tue, Apr 4, 2017 at 12:12 AM, Stephen Frost wrote: > I'm very curious what you're thinking here? IIRC, Andrew had some ideas > for how to do true cross-version testing with TAP in the buildfarm, but > I don't think we actually have that yet..? I heard about nothing in

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

Andres, * Andres Freund (and...@anarazel.de) wrote: > I don't fundamentally disagree with anything here, but I think it'd be a > serious mistake to link this to the conversion of the pg_upgrade tests > to tap tests. I agree that we should move forward with that conversion, regardless of the rest

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On 2017-04-03 11:34:52 -0400, Stephen Frost wrote: > Peter, > > * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > > On 4/3/17 09:07, Michael Paquier wrote: > > > I had for some time a WIP patch on which dust has accumulated, so > > > attached is a more polished version. In more

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

Peter, * Peter Eisentraut (peter.eisentr...@2ndquadrant.com) wrote: > On 4/3/17 09:07, Michael Paquier wrote: > > I had for some time a WIP patch on which dust has accumulated, so > > attached is a more polished version. In more details, here is what > > happens: > > - test.sh is removed. > > -

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On 2017-04-03 11:22:02 -0400, Peter Eisentraut wrote: > On 4/3/17 09:07, Michael Paquier wrote: > > I had for some time a WIP patch on which dust has accumulated, so > > attached is a more polished version. In more details, here is what > > happens: > > - test.sh is removed. > > - vcregress.pl

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On 4/3/17 09:07, Michael Paquier wrote: > I had for some time a WIP patch on which dust has accumulated, so > attached is a more polished version. In more details, here is what > happens: > - test.sh is removed. > - vcregress.pl loses upgradecheck. > - The new test is added. In the case of MSVC

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

Craig, Michael, * Craig Ringer (cr...@2ndquadrant.com) wrote: > On 3 April 2017 at 21:07, Michael Paquier wrote: > > I am parking that in the next commit fest. > > Great. > > Count me in as reviewer, and feel free to poke me if I get caught up > in other things. I'm

Re: [HACKERS] Rewriting the test of pg_upgrade as a TAP test

On 3 April 2017 at 21:07, Michael Paquier wrote: > Hi all, > > The $subject has been mentioned a couple of times already, the last > one being here: > https://www.postgresql.org/message-id/20170401072814.ga2528...@tornado.leadboat.com > > The code tree has to maintain

[HACKERS] Rewriting the test of pg_upgrade as a TAP test

Hi all, The $subject has been mentioned a couple of times already, the last one being here: https://www.postgresql.org/message-id/20170401072814.ga2528...@tornado.leadboat.com The code tree has to maintain now two set of scripts for the same test: test.sh for all *nix platforms, and vcregress.pl