Re: [HACKERS] Regression tests vs existing users in an installation - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: [HACKERS] Regression tests vs existing users in an installation
Date
Msg-id 20190628154110.GM2480@tamriel.snowman.net
Whole thread Raw
In response to Re: [HACKERS] Regression tests vs existing users in an installation  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] Regression tests vs existing users in an installation
Re: [HACKERS] Regression tests vs existing users in an installation
List pgsql-hackers
Greetings,

* Tom Lane (tgl@sss.pgh.pa.us) wrote:
>     Furthermore, while you can do "make install" and "make installcheck"
>     in this directory or its children, it is HIGHLY NOT ADVISED to do so
>     with a server containing valuable data.  Some of these tests may have
>     undesirable side-effects on roles or other global objects within the
>     tested server.
>
> Defining things this way also makes it a non-problem that
> src/test/modules/test_pg_dump creates global objects and doesn't drop
> them.

Sounds like a good approach to me and I'm happy that it'd address the
test_pg_dump case too.

> Now, this doesn't in itself fix the problem that my proposed patch will
> emit warnings about the rolenames test script creating "Public" and so on.
> We could fix that by maintaining a variant expected-file that includes
> those warnings, but probably a less painful answer is just to jack
> client_min_messages up to ERROR for that short segment of the test script.

Seems alright.

> We could make the new subdirectory be something specific like
> "src/test/modules/test_rolenames", but I think very likely we'll be
> wanting some additional test scripts that we likewise deem unsafe to
> run during "installcheck".  So I'd rather choose a more generic module
> name, but I'm not sure what ... "unsafe_tests"?

Agreed but haven't got any particularly good suggestions on names..

Thanks,

Stephen

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Option to dump foreign data in pg_dump
Next
From: Julien Rouhaud
Date:
Subject: Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activityview?