Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Amir Rohan <amir(dot)rohan(at)zoho(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Greg Smith <gsmith(at)gregsmith(dot)com>
Subject: Re: Re: In-core regression tests for replication, cascading, archiving, PITR, etc.
Date: 2015-12-02 04:04:35
Message-ID: CAB7nPqS2RmpAxP=HHP=s_RYdpyRXVUUtT=+f0xxen4rm4GPmOQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 2, 2015 at 12:01 PM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> Michael Paquier wrote:
>> On Wed, Dec 2, 2015 at 8:11 AM, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> wrote:
>
>> > - It would be nice to have command_ok and command_fails in PostgresNode
>> > too; that would remove the need for setting $ENV{PGPORT} but it's
>> > possible to run commands outside a node too, so we'd need duplicates,
>> > which would be worse.
>>
>> I am fine to let it the way your patch does it. There are already many changes.
>
> Idea: we can have a bare command_ok exported by TestLib just as
> currently, and instance method PostgresNode->command_ok that first sets
> local $ENV{PGPORT} and then calls the other one.

Hm. That would be cleaner and make the code more consistent. Now as
TestLib exports command_ok, command_like and command_fails, we would
get redefinition errors when compiling the code if those routines are
not named differently in PostgresNode. If you want to have the names
consistent, then I guess that the only way would be to remove those
routines from the export list of TestLib and call them directly as for
example TestLib::command_ok(). See for example the patch attached that
applies on top on your patch 2 that adds a set of routines in
PostgresNode with a slightly different name.

>> > Finally, I ran perltidy on all the files, which strangely changed stuff
>> > that I didn't expect it to change. I wonder if this is related to the
>> > perltidy version. Do you see further changes if you run perltidy on the
>> > patched tree?
>>
>> SimpleTee.pm shows some diffs, though it doesn't seem that this patch
>> should care about that. The rest is showing no diffs. And I have used
>> perltidy v20140711.
>
> Yes, the patch doesn't modify SimpleTee -- I just used "find" to indent
> perl files. What I don't understand is why doesn't my perltidy run
> match what was in master currently. It should be a no-op ...

Well I don't get it either :)
I did a run on top of your two patches and saw no differences.
--
Michael

Attachment Content-Type Size
20151202_taptests-3.patch application/x-patch 12.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kouhei Kaigai 2015-12-02 05:04:39 Re: Foreign join pushdown vs EvalPlanQual
Previous Message Kyotaro HORIGUCHI 2015-12-02 04:00:45 Re: Freeze avoidance of very large table.