Add a regression test for allow_system_table_mods
Add a regression test file that exercises the kinds of commands that allow_system_table_mods allows. This is put in the "unsafe_tests" suite, so it won't accidentally create a mess if someone runs the normal regression tests against an instance that they care about. Reviewed-by: Tom Lane <[hidden email]> Discussion: https://www.postgresql.org/message-id/flat/8b00ea5e-28a7-88ba-e848-21528b632354%402ndquadrant.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/7fc380f83d466b43a8f65bb52c925c1ab19736ea Modified Files -------------- src/test/modules/unsafe_tests/Makefile | 2 +- .../unsafe_tests/expected/alter_system_table.out | 168 +++++++++++++++++++ .../unsafe_tests/sql/alter_system_table.sql | 185 +++++++++++++++++++++ src/test/regress/expected/alter_table.out | 4 - src/test/regress/sql/alter_table.sql | 4 - 5 files changed, 354 insertions(+), 9 deletions(-) |
Peter Eisentraut <[hidden email]> writes:
> Add a regression test for allow_system_table_mods Oooh ... some of the buildfarm members are pointing out that this didn't follow a project convention: @@ -153,6 +153,7 @@ ROLLBACK; -- reserved tablespace name CREATE TABLESPACE pg_foo LOCATION '/no/such/location'; +WARNING: tablespaces created by regression test cases should have names starting with "regress_" ERROR: directory "/no/such/location" does not exist -- triggers CREATE TRIGGER t1 BEFORE INSERT ON pg_description EXECUTE FUNCTION tf1(); regards, tom lane |
On 2019-11-29 16:27, Tom Lane wrote:
> Peter Eisentraut <[hidden email]> writes: >> Add a regression test for allow_system_table_mods > > Oooh ... some of the buildfarm members are pointing out that this > didn't follow a project convention: Um, yes, that's why it's in unsafe_tests. Is there a way around this? > > @@ -153,6 +153,7 @@ > ROLLBACK; > -- reserved tablespace name > CREATE TABLESPACE pg_foo LOCATION '/no/such/location'; > +WARNING: tablespaces created by regression test cases should have names starting with "regress_" > ERROR: directory "/no/such/location" does not exist > -- triggers > CREATE TRIGGER t1 BEFORE INSERT ON pg_description EXECUTE FUNCTION tf1(); > > regards, tom lane > -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services |
Peter Eisentraut <[hidden email]> writes:
> On 2019-11-29 16:27, Tom Lane wrote: >> Oooh ... some of the buildfarm members are pointing out that this >> didn't follow a project convention: > Um, yes, that's why it's in unsafe_tests. Is there a way around this? Sure, just change the test tablespace's name to follow the convention: >> +WARNING: tablespaces created by regression test cases should have names starting with "regress_" I agree that this is somewhat pointless in the case of an "unsafe" test. But using a different name isn't going to invalidate the test case, so there's not really a reason to not follow the convention. And trying to have an exception for unsafe_tests seems like a lot more trouble than it'd be worth. regards, tom lane |
On Fri, Nov 29, 2019 at 11:09:06AM -0500, Tom Lane wrote:
> I agree that this is somewhat pointless in the case of an "unsafe" test. > But using a different name isn't going to invalidate the test case, > so there's not really a reason to not follow the convention. And > trying to have an exception for unsafe_tests seems like a lot more > trouble than it'd be worth. Yeah, I agree that it would be just more simple to make the unsafe test adopt the convention and be done with it. Could you fix it please? longfin and mantid (as well as anybody running the unsafe tests by themselves) are complaining for three days now. -- Michael |
In reply to this post by Tom Lane-2
On 2019-11-29 17:09, Tom Lane wrote:
>>> +WARNING: tablespaces created by regression test cases should have names starting with "regress_" > I agree that this is somewhat pointless in the case of an "unsafe" test. > But using a different name isn't going to invalidate the test case, > so there's not really a reason to not follow the convention. And > trying to have an exception for unsafe_tests seems like a lot more > trouble than it'd be worth. The test case is specifically testing tablespace names starting with "pg_": -- reserved tablespace name CREATE TABLESPACE pg_foo LOCATION '/no/such/location'; ERROR: unacceptable tablespace name "pg_foo" DETAIL: The prefix "pg_" is reserved for system tablespaces. So using a name starting with "regress_" instead isn't going to help. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services |
Peter Eisentraut <[hidden email]> writes:
> On 2019-11-29 17:09, Tom Lane wrote: >> But using a different name isn't going to invalidate the test case, > The test case is specifically testing tablespace names starting with "pg_": > -- reserved tablespace name > CREATE TABLESPACE pg_foo LOCATION '/no/such/location'; > ERROR: unacceptable tablespace name "pg_foo" > DETAIL: The prefix "pg_" is reserved for system tablespaces. Oh, I see. But is testing that specific error case really worth the trouble it's going to be to make this pass with or without -DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS ? One way would be to provide a variant expected-file, but that's not going to be fun for future maintenance of the test script. Another simple answer is to crank up client_min_messages for this one test to hide the WARNING, but you could conjure scenarios where that misses something important. (Of course, not running the test at all would also miss any such issue.) regards, tom lane |
On Mon, Dec 02, 2019 at 10:11:40AM -0500, Tom Lane wrote:
> One way would be to provide a variant expected-file, but that's not going > to be fun for future maintenance of the test script. Another simple > answer is to crank up client_min_messages for this one test to hide the > WARNING, but you could conjure scenarios where that misses something > important. (Of course, not running the test at all would also miss > any such issue.) Alternate output files should be IMO avoided if we can, so if I were to choose sneaking a SET client_min_messages would be fine, but only for the second create tablespace.. -- Michael |
On 2019-12-03 05:12, Michael Paquier wrote:
> On Mon, Dec 02, 2019 at 10:11:40AM -0500, Tom Lane wrote: >> One way would be to provide a variant expected-file, but that's not going >> to be fun for future maintenance of the test script. Another simple >> answer is to crank up client_min_messages for this one test to hide the >> WARNING, but you could conjure scenarios where that misses something >> important. (Of course, not running the test at all would also miss >> any such issue.) > > Alternate output files should be IMO avoided if we can, so if I were > to choose sneaking a SET client_min_messages would be fine, but only > for the second create tablespace.. Fixed that way. I didn't realize it was a warning that could be silenced that way. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services |
Free forum by Nabble | Edit this page |