Horton

Thread

Commits

  1. Ignore more environment variables in TAP tests

  1. TAP tests still sensitive to various PG* environment variables

    Michael Paquier <michael@paquier.xyz> — 2021-06-02T01:49:01Z

    Hi all,

While looking at a separate issue, I have noticed that TestLib.pm is
lagging behind in terms of environment variables it had better mask to
avoid failures:
https://www.postgresql.org/message-id/YLXjFOV3teAPirmS@paquier.xyz

Once I began playing with the variables not covered yet, and tested
fancy cases with junk values, I have been able to see various failures
in the TAP tests, mainly with authentication and SSL.

Attached is a patch to strengthen all that, which I think we'd better
backpatch.

Any objections to that?
--
Michael

  2. Re: TAP tests still sensitive to various PG* environment variables

    Daniel Gustafsson <daniel@yesql.se> — 2021-06-02T08:39:56Z

    > On 2 Jun 2021, at 03:49, Michael Paquier <michael@paquier.xyz> wrote:

> Attached is a patch to strengthen all that, which I think we'd better
> backpatch.

+1

> Any objections to that?

Seems like a good idea, to keep test invocation stable across branches, minus
PGSSLCRLDIR and PGSSLSNI which are only available in HEAD etc.

--
Daniel Gustafsson		https://vmware.com/

  3. Re: TAP tests still sensitive to various PG* environment variables

    Andrew Dunstan <andrew@dunslane.net> — 2021-06-02T19:43:46Z

    On 6/1/21 9:49 PM, Michael Paquier wrote:
> Hi all,
>
> While looking at a separate issue, I have noticed that TestLib.pm is
> lagging behind in terms of environment variables it had better mask to
> avoid failures:
> https://www.postgresql.org/message-id/YLXjFOV3teAPirmS@paquier.xyz
>
> Once I began playing with the variables not covered yet, and tested
> fancy cases with junk values, I have been able to see various failures
> in the TAP tests, mainly with authentication and SSL.
>
> Attached is a patch to strengthen all that, which I think we'd better
> backpatch.
>
> Any objections to that?



This is a bit gruesome:


    +    delete $ENV{PGCHANNELBINDING};
    +    delete $ENV{PGCLIENTENCODING};
         delete $ENV{PGCONNECT_TIMEOUT};
         delete $ENV{PGDATA};
         delete $ENV{PGDATABASE};
    +    delete $ENV{PGGSSENCMODE};
    +    delete $ENV{PGGSSLIB};
         delete $ENV{PGHOSTADDR};
    +    delete $ENV{PGKRBSRVNAME};
    +    delete $ENV{PGPASSFILE};
    +    delete $ENV{PGPASSWORD};
    +    delete $ENV{PGREQUIREPEER};
         delete $ENV{PGREQUIRESSL};
         delete $ENV{PGSERVICE};
    +    delete $ENV{PGSERVICEFILE};
    +    delete $ENV{PGSSLCERT};
    +    delete $ENV{PGSSLCRL};
    +    delete $ENV{PGSSLCRLDIR};
    +    delete $ENV{PGSSLKEY};
    +    delete $ENV{PGSSLMAXPROTOCOLVERSION};
    +    delete $ENV{PGSSLMINPROTOCOLVERSION};
         delete $ENV{PGSSLMODE};
    +    delete $ENV{PGSSLROOTCERT};
    +    delete $ENV{PGSSLSNI};
         delete $ENV{PGUSER};
         delete $ENV{PGPORT};
         delete $ENV{PGHOST};



Let's change it to something like:


    my @scrubkeys = qw ( PGCHANNELBINDING

       PGCLIENTENCODING PGCONNECT_TIMEOUT PGDATA

       ...

        );

    delete @ENV{@scrubkeys};


cheers


andrew


-- 

Andrew Dunstan
EDB: https://www.enterprisedb.com

  4. Re: TAP tests still sensitive to various PG* environment variables

    Michael Paquier <michael@paquier.xyz> — 2021-06-03T03:03:53Z

    On Wed, Jun 02, 2021 at 03:43:46PM -0400, Andrew Dunstan wrote:
> Let's change it to something like:
>
>     my @scrubkeys = qw ( PGCHANNELBINDING
>        PGCLIENTENCODING PGCONNECT_TIMEOUT PGDATA
>        ...
>         );
>     delete @ENV{@scrubkeys};

Good idea.  I have used that.  Thanks.
--
Michael

  5. Re: TAP tests still sensitive to various PG* environment variables

    Michael Paquier <michael@paquier.xyz> — 2021-06-03T03:10:25Z

    On Wed, Jun 02, 2021 at 10:39:56AM +0200, Daniel Gustafsson wrote:
> Seems like a good idea, to keep test invocation stable across branches, minus
> PGSSLCRLDIR and PGSSLSNI which are only available in HEAD etc.

Right.  This took me a couple of hours to make consistent across
all the branches.  After more review, I have found also about
PGTARGETSESSIONATTRS that would take down the recovery tests as of
10~.  Fun.
--
Michael