From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Regression tests vs existing users in an installation |
Date: | 2019-06-28 15:41:11 |
Message-ID: | 20190628154110.GM2480@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greetings,
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2019-06-28 15:46:24 | Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view? |
Previous Message | Tom Lane | 2019-06-28 15:30:37 | Re: Option to dump foreign data in pg_dump |