Thread: Re: pgsql: Add a regression test for allow_system_table_mods
Peter Eisentraut <peter@eisentraut.org> 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 <peter@eisentraut.org> 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 <peter.eisentraut@2ndquadrant.com> 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
Attachment
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 <peter.eisentraut@2ndquadrant.com> 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
Attachment
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