Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-06-05 Thread Michael Paquier
On Sat, Jun 04, 2022 at 12:35:45PM +0900, Michael Paquier wrote: > Something like 80~85% of the bloat comes from the diffs in your case. > Well, it is always possible to limit that to an arbitrary amount of > characters (say 50k~100k?) to still give some context, and dump the > whole in a different

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-06-03 Thread Michael Paquier
On Fri, Jun 03, 2022 at 12:53:18PM -0700, Andres Freund wrote: > [...] TRAP: FailedAssertion("AmIoWorkerProcess()", File: "xlog.c", Line: 4860, PID: 35325) > regress_log_002_pg_upgrade.log includes all of 002_pg_upgrade_old_node.log and > 002_pg_upgrade_new_node.log. The old node's log includes a

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-06-03 Thread Andres Freund
Hi, I just saw a pg_upgrade failure on my aio branch [1]. Not sure what caused it yet. The reason I'm writing in this thread is that I looked at the regress_log_* for the failure, and found it to be 14.95MiB (which crashed the browser on my phone...). https://api.cirrus-ci.com/v1/artifact/task/51

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-05-20 Thread Michael Paquier
On Fri, May 20, 2022 at 06:28:01PM -0700, Noah Misch wrote: > Looks successful. Thanks a lot for confirming. I have applied that on HEAD, then. -- Michael signature.asc Description: PGP signature

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-05-20 Thread Noah Misch
On Wed, May 18, 2022 at 06:20:08PM +0900, Michael Paquier wrote: > Attached is an updated patch to address your concerns. Looks successful.

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-05-18 Thread Michael Paquier
On Wed, May 18, 2022 at 01:03:15AM -0700, Noah Misch wrote: > On Mon, May 16, 2022 at 02:30:00PM +0900, Michael Paquier wrote: >> Because the shape of the new names does not change the test coverage >> ("regression" prefix or the addition of the double quotes with >> backslashes for all the databas

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-05-18 Thread Noah Misch
On Mon, May 16, 2022 at 02:30:00PM +0900, Michael Paquier wrote: > On Sat, May 14, 2022 at 01:27:28AM -0700, Noah Misch wrote: > > Here, I requested the rationale for the differences you had just described. > > You made a choice to stop testing one list of database names and start > > testing > >

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-05-15 Thread Michael Paquier
On Sat, May 14, 2022 at 01:27:28AM -0700, Noah Misch wrote: > Here, I requested the rationale for the differences you had just described. > You made a choice to stop testing one list of database names and start testing > a different list of database names. Why? Because the shape of the new names

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-05-14 Thread Noah Misch
On Thu, May 12, 2022 at 02:27:30PM +0900, Michael Paquier wrote: > On Tue, May 10, 2022 at 10:32:55PM -0700, Noah Misch wrote: > > On Wed, May 11, 2022 at 10:29:44AM +0900, Michael Paquier wrote: > > > On Mon, May 09, 2022 at 12:18:39PM +0900, Michael Paquier wrote: > > > > All these fixes lead me

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-05-11 Thread Michael Paquier
On Tue, May 10, 2022 at 10:32:55PM -0700, Noah Misch wrote: > Why did you discontinue testing the longstanding test database name? I am not sure what you mean here. Are you saying that the test should be changed to prefix each database name by "regression", as it was the case in test.sh? Or do y

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-05-10 Thread Noah Misch
On Wed, May 11, 2022 at 10:29:44AM +0900, Michael Paquier wrote: > On Mon, May 09, 2022 at 12:18:39PM +0900, Michael Paquier wrote: > > All these fixes lead me to the attached patch. > > I have applied this stuff as of 7dd3ee5, in time for beta1, and closed > the open item. One difference is that

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-05-10 Thread Michael Paquier
On Mon, May 09, 2022 at 12:18:39PM +0900, Michael Paquier wrote: > All these fixes lead me to the attached patch. I have applied this stuff as of 7dd3ee5, in time for beta1, and closed the open item. One difference is that I've added one backslash surrounding the double quote at the beginning *an

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-05-08 Thread Michael Paquier
On Sun, May 01, 2022 at 09:27:18PM -0700, Noah Misch wrote: > On Fri, Apr 01, 2022 at 10:16:48AM +0900, Michael Paquier wrote: >> commit 322becb wrote: > > Nothing checks the command result, so the test file passes even if each of > these createdb calls fails. Other run_log() calls in this file ha

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-05-02 Thread Michael Paquier
On Sun, May 01, 2022 at 09:27:18PM -0700, Noah Misch wrote: > commit 322becb wrote: Thanks, Noah. I am out this week, but I should be able to address all your points at the beginning of next week. I have added an open item for now. -- Michael signature.asc Description: PGP signature

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-05-01 Thread Noah Misch
On Fri, Apr 01, 2022 at 10:16:48AM +0900, Michael Paquier wrote: > On Thu, Mar 31, 2022 at 09:49:50AM -0400, Tom Lane wrote: > > Well, let's go ahead with it and see what happens. If it's too > > much of a mess we can always revert. > > Okay, done after an extra round of self-review. commit 322b

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-04-01 Thread Michael Paquier
On Fri, Apr 01, 2022 at 08:34:34AM -0500, Justin Pryzby wrote: > If you do that, should also remove upgradecheck from .cirrus.yaml, which > currently runs the upgradecheck target. Indeed. It makes no sense to keep that. I have removed this part and applied the patch, after one extra run through

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-04-01 Thread Justin Pryzby
On Fri, Apr 01, 2022 at 08:53:10PM +0900, Michael Paquier wrote: > On Fri, Apr 01, 2022 at 03:01:38PM +0900, Michael Paquier wrote: > > On Thu, Mar 31, 2022 at 10:51:59PM -0500, Justin Pryzby wrote: > >> Is diff -q defined somewhere ? I can't find it in postgres sources nor in > >> sources for bf

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-04-01 Thread Michael Paquier
On Fri, Apr 01, 2022 at 03:01:38PM +0900, Michael Paquier wrote: > On Thu, Mar 31, 2022 at 10:51:59PM -0500, Justin Pryzby wrote: >> Is diff -q defined somewhere ? I can't find it in postgres sources nor in >> sources for bf client. > > 322becb has added such a call, at the end of 002_pg_upgrade.

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-03-31 Thread Michael Paquier
On Thu, Mar 31, 2022 at 10:51:59PM -0500, Justin Pryzby wrote: > Is diff -q defined somewhere ? I can't find it in postgres sources nor in > sources for bf client. 322becb has added such a call, at the end of 002_pg_upgrade.pl. vcregress.pl also has one before this commit. -- Michael signature.

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-03-31 Thread Michael Paquier
On Thu, Mar 31, 2022 at 08:42:41PM -0700, Noah Misch wrote: > The failure looked like this: > > # Running: diff -q > /export/home/nm/farm/studio64v12_6/HEAD/pgsql.build/src/bin/pg_upgrade/tmp_check/tmp_test_lPFv/dump1.sql > > /export/home/nm/farm/studio64v12_6/HEAD/pgsql.build/src/bin/pg_upgrad

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-03-31 Thread Michael Paquier
On Fri, Apr 01, 2022 at 10:16:48AM +0900, Michael Paquier wrote: > Okay, done after an extra round of self-review. I have finished by > tweaking a couple of comments, and adjusted further TESTING to explain > what needs to be done to have a dump compatible with the test. Let's > now see what goes

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-03-31 Thread Justin Pryzby
On Thu, Mar 31, 2022 at 08:42:41PM -0700, Noah Misch wrote: > On Fri, Apr 01, 2022 at 10:16:48AM +0900, Michael Paquier wrote: > > On Thu, Mar 31, 2022 at 09:49:50AM -0400, Tom Lane wrote: > > > Well, let's go ahead with it and see what happens. If it's too > > > much of a mess we can always rever

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-03-31 Thread Noah Misch
On Fri, Apr 01, 2022 at 10:16:48AM +0900, Michael Paquier wrote: > On Thu, Mar 31, 2022 at 09:49:50AM -0400, Tom Lane wrote: > > Well, let's go ahead with it and see what happens. If it's too > > much of a mess we can always revert. > > Okay, done after an extra round of self-review. I have fini

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-03-31 Thread Michael Paquier
On Thu, Mar 31, 2022 at 09:49:50AM -0400, Tom Lane wrote: > Well, let's go ahead with it and see what happens. If it's too > much of a mess we can always revert. Okay, done after an extra round of self-review. I have finished by tweaking a couple of comments, and adjusted further TESTING to expl

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-03-31 Thread Tom Lane
Michael Paquier writes: > On Wed, Mar 30, 2022 at 10:36:16PM -0700, Andres Freund wrote: >> On 2022-03-31 01:00:14 -0400, Tom Lane wrote: >>> How well does this patch work with pre-14 buildfarm clients? >> Looks to me like it'll just run the test twice, once via TestUpgrade, once >> via >> tapte

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-03-31 Thread Michael Paquier
On Wed, Mar 30, 2022 at 10:36:16PM -0700, Andres Freund wrote: > On 2022-03-31 01:00:14 -0400, Tom Lane wrote: > > How well does this patch work with pre-14 buildfarm clients? > > Looks to me like it'll just run the test twice, once via TestUpgrade, once via > taptest. It's possible that there cou

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-03-30 Thread Andres Freund
On 2022-03-31 01:00:14 -0400, Tom Lane wrote: > How well does this patch work with pre-14 buildfarm clients? Looks to me like it'll just run the test twice, once via TestUpgrade, once via taptest. It's possible that there could be trouble somehow due to duplicated log files or something?

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-03-30 Thread Tom Lane
I wrote: > There's still about a third of the buildfarm running older > client releases --- I count > 2 REL_8 > 2 REL_10 > 13 REL_11 > 6 REL_12 > 16 REL_13.1 > 89 REL_14 Wait a minute ... actually, what's most relevant here is the population running TAP tests, whi

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-03-30 Thread Tom Lane
Michael Paquier writes: > So, any particular feelings about this patch? This has been around > for a couple of months/years now, so it could be a good time to do the > switch now rather than wait an extra year, or even the beginning of > the next release cycle. And the buildfarm is already able

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-03-30 Thread Michael Paquier
On Thu, Mar 03, 2022 at 02:03:38PM +0900, Michael Paquier wrote: > Indeed. I have reworked the whole, rather than just those three > sentences. So, any particular feelings about this patch? This has been around for a couple of months/years now, so it could be a good time to do the switch now rat

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-03-03 Thread Andrew Dunstan
On 3/3/22 00:03, Michael Paquier wrote: >>> +if ( (defined($ENV{olddump}) && !defined($ENV{oldinstall})) >>> + || (!defined($ENV{olddump}) && defined($ENV{oldinstall}))) >> Odd indentation. Spaces between parens? > Well, perltidy tells me that this is right. > > Yeah, I haven't found a way t

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-03-02 Thread Michael Paquier
On Wed, Mar 02, 2022 at 12:07:29AM -0800, Andres Freund wrote: >> +++ b/src/bin/pg_upgrade/t/001_basic.pl >> @@ -0,0 +1,9 @@ >> +use strict; >> +use warnings; >> + >> +use PostgreSQL::Test::Utils; >> +use Test::More tests => 8; > > Outdated. Fixed. >> +program_help_ok('pg_upgrade'); >> +program_

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-03-02 Thread Michael Paquier
On Wed, Mar 02, 2022 at 12:01:17AM -0800, Andres Freund wrote: > But in a bad way, because EXTRA_REGRESS_OPTS now always wins, even for stuff > we want to override. Note how test.sh explicitly specifies port, bindir etc > after the pre-existing EXTRA_REGRESS_OPTS. Ah, right. Will fix. -- Michael

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-03-02 Thread Andres Freund
Hi, On 2022-03-02 15:57:23 +0900, Michael Paquier wrote: > Do others have an opinion about a backpatch of the bugfix? Nobody has > complained about that since pg_upgrade exists, so I have just done the > change on HEAD. WFM. > +++ b/src/bin/pg_upgrade/t/001_basic.pl > @@ -0,0 +1,9 @@ > +use s

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-03-02 Thread Andres Freund
On 2022-02-15 13:02:41 +0900, Michael Paquier wrote: > >> + @regress_command = (@regress_command, @extra_opts); > >> + > >> + $oldnode->command_ok(@regress_command, > >> + 'regression test run on old instance'); > > > > I also think this should take EXTRA_REGRESS_OPTS into account - tes

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-03-01 Thread Michael Paquier
On Wed, Feb 16, 2022 at 01:58:10PM +0900, Michael Paquier wrote: > I have been looking at how much simplicity this brings, and I have to > admit that it is tempting to just support the loading of dumps when > setting up the old instance to upgrade from. We'd still need to do an > extra effort in t

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-02-15 Thread Michael Paquier
On Tue, Feb 15, 2022 at 01:02:41PM +0900, Michael Paquier wrote: > Hmm. At the end of the day, I am wondering whether we should not give > up entirely on the concept of running the regression tests on older > branches in the TAP script of a newer branch. pg_regress needs to > come from the old so

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-02-14 Thread Michael Paquier
On Sat, Feb 12, 2022 at 08:50:41PM -0800, Andres Freund wrote: > On 2022-01-18 11:20:16 +0900, Michael Paquier wrote: >> +# required for 002_pg_upgrade.pl >> +REGRESS_SHLIB=$(abs_top_builddir)/src/test/regress/regress$(DLSUFFIX) >> +export REGRESS_SHLIB > > It seems weird to propagate this into mu

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-02-14 Thread Michael Paquier
On Sat, Feb 12, 2022 at 08:12:42PM -0800, Andres Freund wrote: > It also doesn't handle @ correctly. Makes sense to fix. Should probably use > the same logic that libpq, psql, ... use? > > if (is_unixsock_path(ch->host)) > ch->type = CHT_UNIX_SOC

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-02-13 Thread Michael Paquier
On Sun, Feb 13, 2022 at 02:55:26PM -0800, Andres Freund wrote: > On 2022-02-14 11:23:18 +1300, Thomas Munro wrote: >> Ahh, right. I assume it still needs perl2host() treatment for MSYS2 >> systems, because jacana's log shows TESTDIR is set to a Unixoid path >> that I assume pg_regress's runtime ca

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-02-13 Thread Andres Freund
On 2022-02-14 11:23:18 +1300, Thomas Munro wrote: > On Sun, Feb 13, 2022 at 6:29 PM Andres Freund wrote: > > Afaics all the "regress test inside tap test" cases would need to do is to > > pass > > --outputdir=${PostgreSQL::Test::Utils::tmp_check} and you'd get exactly the > > same path as > > RE

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-02-13 Thread Thomas Munro
On Sun, Feb 13, 2022 at 6:29 PM Andres Freund wrote: > Afaics all the "regress test inside tap test" cases would need to do is to > pass > --outputdir=${PostgreSQL::Test::Utils::tmp_check} and you'd get exactly the > same path as > REGRESS_OUTPUTDIR currently provides. Ahh, right. I assume it

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-02-12 Thread Andres Freund
Hi, On 2022-02-13 18:07:30 +1300, Thomas Munro wrote: > On Sun, Feb 13, 2022 at 5:50 PM Andres Freund wrote: > >> > +# required for 027_stream_regress.pl > >> > +REGRESS_OUTPUTDIR=$(abs_top_builddir)/src/test/recovery > >> > +export REGRESS_OUTPUTDIR > >> > >> Why do we need this? > > > > The Mak

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-02-12 Thread Tom Lane
Thomas Munro writes: > I thought it was a goal that VPATH builds shouldn't pollute the source > tree, but the Make macro prove_check is explicitly doing so by > default. Perhaps *that* should be fixed? Indeed. That seems broken by definition. More generally, I thought we'd established a conven

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-02-12 Thread Thomas Munro
On Sun, Feb 13, 2022 at 5:50 PM Andres Freund wrote: > On 2022-01-18 11:20:16 +0900, Michael Paquier wrote: > > +REGRESS_OUTPUTDIR=$(abs_top_builddir)/src/bin/pg_upgrade > > +export REGRESS_OUTPUTDIR > > I don't really understand why 027_stream_regress.pl is using this (and thus > not why it's use

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-02-12 Thread Andres Freund
Hi, On 2022-01-18 11:20:16 +0900, Michael Paquier wrote: > +# required for 002_pg_upgrade.pl > +REGRESS_SHLIB=$(abs_top_builddir)/src/test/regress/regress$(DLSUFFIX) > +export REGRESS_SHLIB It seems weird to propagate this into multiple places. Why don't we define that centrally? Although it's w

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-02-12 Thread Andres Freund
Hi, On 2022-01-18 11:20:16 +0900, Michael Paquier wrote: > On Sat, Jan 15, 2022 at 01:52:39PM +0800, Julien Rouhaud wrote: > > libpq environment variable PGHOST has a non-local server value: > > C:/Users/ContainerAdministrator/AppData/Local/Temp/FhBIlsw6SV > > Failure, exiting > > not ok 3 - run

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-01-17 Thread Michael Paquier
On Sat, Jan 15, 2022 at 01:52:39PM +0800, Julien Rouhaud wrote: > libpq environment variable PGHOST has a non-local server value: > C:/Users/ContainerAdministrator/AppData/Local/Temp/FhBIlsw6SV > Failure, exiting > not ok 3 - run of pg_upgrade for new instance There are two things here, as far as

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-01-14 Thread Julien Rouhaud
Hi, On Tue, Jan 11, 2022 at 04:14:25PM +0900, Michael Paquier wrote: > The CF bot is unhappy, so here is a rebase, with some typo fixes > reported by Justin offlist. The cfbot still complains about this patch on Windows: https://cirrus-ci.com/task/6411385683836928 https://api.cirrus-ci.com/v1/art

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-01-10 Thread Michael Paquier
On Wed, Jan 05, 2022 at 05:12:41PM +0900, Michael Paquier wrote: > Rebased patch to cool down the CF bot, as per the addition of > --no-sync to pg_upgrade. The CF bot is unhappy, so here is a rebase, with some typo fixes reported by Justin offlist. -- Michael From 1d2dc68b8c27d9c328276ed21e57290f6

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2022-01-05 Thread Michael Paquier
On Thu, Dec 16, 2021 at 11:51:55AM +0900, Michael Paquier wrote: > I may have missed one thing or two, but I think that's pretty much > what we should be looking for to do the switch to TAP in terms of > coverage. Rebased patch to cool down the CF bot, as per the addition of --no-sync to pg_upgrad

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-12-15 Thread Michael Paquier
On Wed, Dec 15, 2021 at 10:47:24AM +0900, Michael Paquier wrote: > Missed that, thanks! I'll think about all that a bit more before > sending a long-overdue rebased version. Okay, here is finally a rebase of this patch, where I have fixed a couple of existing issues, and I have extended the patch

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-12-14 Thread Michael Paquier
On Mon, Dec 13, 2021 at 10:14:49PM -0800, Andres Freund wrote: > Tom's point was that the buildfarm scripts do > if ($self->{bfconf}->{using_msvc}) > @checklog = run_log("perl vcregress.pl upgradecheck"); > else > "cd $self->{pgsql}/src/bin/pg_upgra

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-12-13 Thread Andres Freund
On 2021-12-14 14:31:24 +0900, Michael Paquier wrote: > On Mon, Dec 13, 2021 at 06:08:24PM -0800, Andres Freund wrote: > > Seems like we might get away with making make -C contrib/pg_upgrade check > > and > > vcregress.pl upgradecheck do nothing? > > You mean #contrib/#src/bin/# here, right? I do

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-12-13 Thread Michael Paquier
On Mon, Dec 13, 2021 at 06:08:24PM -0800, Andres Freund wrote: > Seems like we might get away with making make -C contrib/pg_upgrade check and > vcregress.pl upgradecheck do nothing? You mean #contrib/#src/bin/# here, right? I don't think that we have any need to have "make -C" do nothing. For v

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-12-13 Thread Andres Freund
Hi, On 2021-10-02 23:34:38 -0400, Tom Lane wrote: > Andrew Dunstan writes: > > On 10/2/21 5:03 PM, Tom Lane wrote: > >> IIUC, the only problem for a non-updated animal would be that it'd > >> run the test twice? Or would it actually fail? If the latter, > >> we'd need to sit on the patch rather

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-10-11 Thread Michael Paquier
On Mon, Oct 11, 2021 at 09:04:47AM -0400, Andrew Dunstan wrote: > Keeping test.sh is not necessary - I mis-remembered what the test module > does. So.. Are people fine to remove entirely test.sh at the end, requiring the tests of pg_upgrade to have TAP installed? I'd rather raise the bar here, a

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-10-11 Thread Michael Paquier
On Sun, Oct 03, 2021 at 08:22:57AM -0400, Andrew Dunstan wrote: > Actually, I was wrong. The module just does "make check" for non-MSVC. > For MSVC it calls vcregress.pl, which the patch doesn't touch (it > should, I think). Yes, it should. And I'd like to do things so as we replace all the inter

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-10-11 Thread Andrew Dunstan
On 10/10/21 10:07 AM, Peter Eisentraut wrote: > On 03.10.21 09:03, Michael Paquier wrote: >> On Sat, Oct 02, 2021 at 11:34:38PM -0400, Tom Lane wrote: >>> Maybe we could leave test.sh in place for awhile?  I'd rather >>> not cause a flag day for buildfarm owners.  (Also, how do we >>> see this wo

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-10-10 Thread Michael Paquier
On Sun, Oct 10, 2021 at 04:07:43PM +0200, Peter Eisentraut wrote: > On 03.10.21 09:03, Michael Paquier wrote: >> On Sat, Oct 02, 2021 at 11:34:38PM -0400, Tom Lane wrote: >>> Maybe we could leave test.sh in place for awhile? I'd rather >>> not cause a flag day for buildfarm owners. (Also, how do

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-10-10 Thread Peter Eisentraut
On 03.10.21 09:03, Michael Paquier wrote: On Sat, Oct 02, 2021 at 11:34:38PM -0400, Tom Lane wrote: Maybe we could leave test.sh in place for awhile? I'd rather not cause a flag day for buildfarm owners. (Also, how do we see this working in the back branches?) I would be fine with test.sh st

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-10-03 Thread Andrew Dunstan
On 10/2/21 11:34 PM, Tom Lane wrote: > Andrew Dunstan writes: >> On 10/2/21 5:03 PM, Tom Lane wrote: >>> IIUC, the only problem for a non-updated animal would be that it'd >>> run the test twice? Or would it actually fail? If the latter, >>> we'd need to sit on the patch rather longer. >> The

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-10-03 Thread Michael Paquier
On Sat, Oct 02, 2021 at 11:34:38PM -0400, Tom Lane wrote: > Maybe we could leave test.sh in place for awhile? I'd rather > not cause a flag day for buildfarm owners. (Also, how do we > see this working in the back branches?) I would be fine with test.sh staying around for now. If we do that, th

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-10-02 Thread Tom Lane
Andrew Dunstan writes: > On 10/2/21 5:03 PM, Tom Lane wrote: >> IIUC, the only problem for a non-updated animal would be that it'd >> run the test twice? Or would it actually fail? If the latter, >> we'd need to sit on the patch rather longer. > The patch removes test.sh, so yes it would break.

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-10-02 Thread Andrew Dunstan
On 10/2/21 5:03 PM, Tom Lane wrote: > Andrew Dunstan writes: >> I haven't looked at the patch closely yet, but from a buildfarm POV I >> think the only thing that needs to be done is to inhibit the buildfarm >> client module if the TAP tests are present. The buildfarm code that runs >> TAP tests

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-10-02 Thread Tom Lane
Andrew Dunstan writes: > I haven't looked at the patch closely yet, but from a buildfarm POV I > think the only thing that needs to be done is to inhibit the buildfarm > client module if the TAP tests are present. The buildfarm code that runs > TAP tests should automatically detect and run the new

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-10-02 Thread Andrew Dunstan
On 10/1/21 2:19 AM, Michael Paquier wrote: > On Thu, May 20, 2021 at 03:07:56PM +0900, Michael Paquier wrote: >> This stuff still needs to be expanded depending on how PostgresNode is >> made backward-compatible, but I'll wait for that to happen before >> going further down here. I have also spe

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-09-30 Thread Michael Paquier
On Thu, May 20, 2021 at 03:07:56PM +0900, Michael Paquier wrote: > This stuff still needs to be expanded depending on how PostgresNode is > made backward-compatible, but I'll wait for that to happen before > going further down here. I have also spent some time testing all that > with MSVC, and the

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-09-07 Thread Michael Paquier
On Tue, Sep 07, 2021 at 02:43:15PM -0700, Rachel Heaton wrote: > Running check tests in the pg_upgrade folder fails for this reason. Thanks, rebased as attached. Andrew has posted another patch set that completely reworks the shape of the modules by moving them into a dedicated namespace, meaning

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-09-07 Thread Rachel Heaton
Hello Michael, This patch needs the update from 201a76183 -- the function `get_new_node` no longer exists. Running check tests in the pg_upgrade folder fails for this reason. Thank you, Rachel On Tue, Sep 7, 2021 at 2:06 PM Michael Paquier wrote: > On Tue, May 18, 2021 at 10:49:39AM +0900, Mi

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-05-19 Thread Michael Paquier
On Tue, May 18, 2021 at 10:49:39AM +0900, Michael Paquier wrote: > Makes sense. For now, I'll update this patch set so as it is possible > to use custom dumps, as an option in parallel of pg_regress when > specifying a different source code path. I'll also decouple the > business with probin upda

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-05-17 Thread Michael Paquier
On Mon, May 17, 2021 at 12:32:13PM -0400, Andrew Dunstan wrote: > On 5/16/21 9:55 PM, Michael Paquier wrote: > Yes, I'm going to be proposing a series of smallish patches including > these when the tree is branched (which I hope will be in a few weeks). Thanks! That clearly needs to happen first.

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-05-17 Thread Andrew Dunstan
On 5/16/21 9:55 PM, Michael Paquier wrote: > On Sat, May 15, 2021 at 02:22:24PM -0400, Andrew Dunstan wrote: >> PostgresNode is currently able to create nodes suitable for upgrade down >> to release 10. If we add '-w' to the 'pg_ctl start' flags that can >> extend down to release 9.5. (Just teste

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-05-16 Thread Michael Paquier
On Sat, May 15, 2021 at 02:22:24PM -0400, Andrew Dunstan wrote: > PostgresNode is currently able to create nodes suitable for upgrade down > to release 10. If we add '-w' to the 'pg_ctl start' flags that can > extend down to release 9.5. (Just tested) I think we should do that > forthwith. '-w' is

Re: Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-05-15 Thread Andrew Dunstan
On 5/14/21 10:26 PM, Michael Paquier wrote: > Hi, > (Adding Andrew in CC for the buildfarm and PostgresNode parts.) > > $subject has been around for a couple of years now, with the following > threads: > https://www.postgresql.org/message-id/20180126080026.gi17...@paquier.xyz > https://www.postgr

Rewriting the test of pg_upgrade as a TAP test - take three - remastered set

2021-05-14 Thread Michael Paquier
Hi, (Adding Andrew in CC for the buildfarm and PostgresNode parts.) $subject has been around for a couple of years now, with the following threads: https://www.postgresql.org/message-id/20180126080026.gi17...@paquier.xyz https://www.postgresql.org/message-id/cab7npqrdan1a1ynjxnl9t1juewct8ttqq29dnv