Regression tests failing if not launched on db "regression"
Hi all,
It happens that the following regression tests are failing if they are
run on a database not named "regression":
- updatable_views
- foreign_data
- sequence
Those tests are failing because some relations of information_schemas
contain information that are database-dependent. Please see the diffs
attached.
Note that this can be easily reproduced by running pg_regress with a
command of this type from src/test/regress:
./pg_regress --inputdir=. --temp-install=./tmp_check \
--top-builddir=../../.. --dlpath=. \
--schedule=./parallel_schedule \
--dbname=foo
IMHO, the regression test suite would gain in consistency and
portability if we do not refer to data that is database-dependent.
Opinions? A patch fixing that would be trivial to do, and I do not
mind writing it. Also, if we consider that as a bug, and I think it
is, the fix should be back-patched as well.
Regards,
--
Michael
Attachments:
dbname_regressions.diffsapplication/octet-stream; name=dbname_regressions.diffsDownload
*** /home/ioltas/make/postgres/src/test/regress/expected/updatable_views.out Thu Dec 5 03:45:03 2013
--- /home/ioltas/make/postgres/src/test/regress/results/updatable_views.out Thu Dec 5 04:08:22 2013
***************
*** 1398,1404 ****
SELECT * FROM information_schema.views WHERE table_name = 'rw_view1';
table_catalog | table_schema | table_name | view_definition | check_option | is_updatable | is_insertable_into | is_trigger_updatable | is_trigger_deletable | is_trigger_insertable_into
---------------+--------------+------------+------------------------------------+--------------+--------------+--------------------+----------------------+----------------------+----------------------------
! regression | public | rw_view1 | SELECT base_tbl.a, +| LOCAL | YES | YES | NO | NO | NO
| | | base_tbl.b +| | | | | |
| | | FROM base_tbl +| | | | | |
| | | WHERE (base_tbl.a < base_tbl.b); | | | | | |
--- 1398,1404 ----
SELECT * FROM information_schema.views WHERE table_name = 'rw_view1';
table_catalog | table_schema | table_name | view_definition | check_option | is_updatable | is_insertable_into | is_trigger_updatable | is_trigger_deletable | is_trigger_insertable_into
---------------+--------------+------------+------------------------------------+--------------+--------------+--------------------+----------------------+----------------------+----------------------------
! foo | public | rw_view1 | SELECT base_tbl.a, +| LOCAL | YES | YES | NO | NO | NO
| | | base_tbl.b +| | | | | |
| | | FROM base_tbl +| | | | | |
| | | WHERE (base_tbl.a < base_tbl.b); | | | | | |
***************
*** 1450,1456 ****
SELECT * FROM information_schema.views WHERE table_name = 'rw_view2';
table_catalog | table_schema | table_name | view_definition | check_option | is_updatable | is_insertable_into | is_trigger_updatable | is_trigger_deletable | is_trigger_insertable_into
---------------+--------------+------------+----------------------------+--------------+--------------+--------------------+----------------------+----------------------+----------------------------
! regression | public | rw_view2 | SELECT rw_view1.a +| CASCADED | YES | YES | NO | NO | NO
| | | FROM rw_view1 +| | | | | |
| | | WHERE (rw_view1.a < 10); | | | | | |
(1 row)
--- 1450,1456 ----
SELECT * FROM information_schema.views WHERE table_name = 'rw_view2';
table_catalog | table_schema | table_name | view_definition | check_option | is_updatable | is_insertable_into | is_trigger_updatable | is_trigger_deletable | is_trigger_insertable_into
---------------+--------------+------------+----------------------------+--------------+--------------+--------------------+----------------------+----------------------+----------------------------
! foo | public | rw_view2 | SELECT rw_view1.a +| CASCADED | YES | YES | NO | NO | NO
| | | FROM rw_view1 +| | | | | |
| | | WHERE (rw_view1.a < 10); | | | | | |
(1 row)
***************
*** 1490,1496 ****
SELECT * FROM information_schema.views WHERE table_name = 'rw_view2';
table_catalog | table_schema | table_name | view_definition | check_option | is_updatable | is_insertable_into | is_trigger_updatable | is_trigger_deletable | is_trigger_insertable_into
---------------+--------------+------------+----------------------------+--------------+--------------+--------------------+----------------------+----------------------+----------------------------
! regression | public | rw_view2 | SELECT rw_view1.a +| LOCAL | YES | YES | NO | NO | NO
| | | FROM rw_view1 +| | | | | |
| | | WHERE (rw_view1.a < 10); | | | | | |
(1 row)
--- 1490,1496 ----
SELECT * FROM information_schema.views WHERE table_name = 'rw_view2';
table_catalog | table_schema | table_name | view_definition | check_option | is_updatable | is_insertable_into | is_trigger_updatable | is_trigger_deletable | is_trigger_insertable_into
---------------+--------------+------------+----------------------------+--------------+--------------+--------------------+----------------------+----------------------+----------------------------
! foo | public | rw_view2 | SELECT rw_view1.a +| LOCAL | YES | YES | NO | NO | NO
| | | FROM rw_view1 +| | | | | |
| | | WHERE (rw_view1.a < 10); | | | | | |
(1 row)
***************
*** 1530,1536 ****
SELECT * FROM information_schema.views WHERE table_name = 'rw_view2';
table_catalog | table_schema | table_name | view_definition | check_option | is_updatable | is_insertable_into | is_trigger_updatable | is_trigger_deletable | is_trigger_insertable_into
---------------+--------------+------------+----------------------------+--------------+--------------+--------------------+----------------------+----------------------+----------------------------
! regression | public | rw_view2 | SELECT rw_view1.a +| NONE | YES | YES | NO | NO | NO
| | | FROM rw_view1 +| | | | | |
| | | WHERE (rw_view1.a < 10); | | | | | |
(1 row)
--- 1530,1536 ----
SELECT * FROM information_schema.views WHERE table_name = 'rw_view2';
table_catalog | table_schema | table_name | view_definition | check_option | is_updatable | is_insertable_into | is_trigger_updatable | is_trigger_deletable | is_trigger_insertable_into
---------------+--------------+------------+----------------------------+--------------+--------------+--------------------+----------------------+----------------------+----------------------------
! foo | public | rw_view2 | SELECT rw_view1.a +| NONE | YES | YES | NO | NO | NO
| | | FROM rw_view1 +| | | | | |
| | | WHERE (rw_view1.a < 10); | | | | | |
(1 row)
***************
*** 1556,1567 ****
SELECT * FROM information_schema.views WHERE table_name LIKE E'rw\\_view_' ORDER BY table_name;
table_catalog | table_schema | table_name | view_definition | check_option | is_updatable | is_insertable_into | is_trigger_updatable | is_trigger_deletable | is_trigger_insertable_into
---------------+--------------+------------+---------------------------+--------------+--------------+--------------------+----------------------+----------------------+----------------------------
! regression | public | rw_view1 | SELECT base_tbl.a +| CASCADED | YES | YES | NO | NO | NO
| | | FROM base_tbl; | | | | | |
! regression | public | rw_view2 | SELECT rw_view1.a +| NONE | YES | YES | NO | NO | NO
| | | FROM rw_view1 +| | | | | |
| | | WHERE (rw_view1.a > 0); | | | | | |
! regression | public | rw_view3 | SELECT rw_view2.a +| CASCADED | YES | YES | NO | NO | NO
| | | FROM rw_view2; | | | | | |
(3 rows)
--- 1556,1567 ----
SELECT * FROM information_schema.views WHERE table_name LIKE E'rw\\_view_' ORDER BY table_name;
table_catalog | table_schema | table_name | view_definition | check_option | is_updatable | is_insertable_into | is_trigger_updatable | is_trigger_deletable | is_trigger_insertable_into
---------------+--------------+------------+---------------------------+--------------+--------------+--------------------+----------------------+----------------------+----------------------------
! foo | public | rw_view1 | SELECT base_tbl.a +| CASCADED | YES | YES | NO | NO | NO
| | | FROM base_tbl; | | | | | |
! foo | public | rw_view2 | SELECT rw_view1.a +| NONE | YES | YES | NO | NO | NO
| | | FROM rw_view1 +| | | | | |
| | | WHERE (rw_view1.a > 0); | | | | | |
! foo | public | rw_view3 | SELECT rw_view2.a +| CASCADED | YES | YES | NO | NO | NO
| | | FROM rw_view2; | | | | | |
(3 rows)
======================================================================
*** /home/ioltas/make/postgres/src/test/regress/expected/foreign_data.out Thu Dec 5 03:45:03 2013
--- /home/ioltas/make/postgres/src/test/regress/results/foreign_data.out Thu Dec 5 04:08:31 2013
***************
*** 838,957 ****
SELECT * FROM information_schema.foreign_data_wrappers ORDER BY 1, 2;
foreign_data_wrapper_catalog | foreign_data_wrapper_name | authorization_identifier | library_name | foreign_data_wrapper_language
------------------------------+---------------------------+--------------------------+--------------+-------------------------------
! regression | dummy | foreign_data_user | | c
! regression | foo | foreign_data_user | | c
! regression | postgresql | foreign_data_user | | c
(3 rows)
SELECT * FROM information_schema.foreign_data_wrapper_options ORDER BY 1, 2, 3;
foreign_data_wrapper_catalog | foreign_data_wrapper_name | option_name | option_value
------------------------------+---------------------------+--------------+--------------
! regression | foo | test wrapper | true
(1 row)
SELECT * FROM information_schema.foreign_servers ORDER BY 1, 2;
foreign_server_catalog | foreign_server_name | foreign_data_wrapper_catalog | foreign_data_wrapper_name | foreign_server_type | foreign_server_version | authorization_identifier
------------------------+---------------------+------------------------------+---------------------------+---------------------+------------------------+--------------------------
! regression | s0 | regression | dummy | | | foreign_data_user
! regression | s4 | regression | foo | oracle | | foreign_data_user
! regression | s5 | regression | foo | | 15.0 | regress_test_role
! regression | s6 | regression | foo | | 16.0 | regress_test_indirect
! regression | s8 | regression | postgresql | | | foreign_data_user
! regression | t1 | regression | foo | | | regress_test_indirect
! regression | t2 | regression | foo | | | regress_test_role
(7 rows)
SELECT * FROM information_schema.foreign_server_options ORDER BY 1, 2, 3;
foreign_server_catalog | foreign_server_name | option_name | option_value
------------------------+---------------------+-----------------+--------------
! regression | s4 | dbname | b
! regression | s4 | host | a
! regression | s6 | dbname | b
! regression | s6 | host | a
! regression | s8 | connect_timeout | 30
! regression | s8 | dbname | db1
(6 rows)
SELECT * FROM information_schema.user_mappings ORDER BY lower(authorization_identifier), 2, 3;
authorization_identifier | foreign_server_catalog | foreign_server_name
--------------------------+------------------------+---------------------
! foreign_data_user | regression | s4
! foreign_data_user | regression | s8
! PUBLIC | regression | s4
! PUBLIC | regression | s8
! PUBLIC | regression | t1
! regress_test_role | regression | s5
! regress_test_role | regression | s6
! regress_test_role | regression | t1
(8 rows)
SELECT * FROM information_schema.user_mapping_options ORDER BY lower(authorization_identifier), 2, 3, 4;
authorization_identifier | foreign_server_catalog | foreign_server_name | option_name | option_value
--------------------------+------------------------+---------------------+--------------+--------------
! foreign_data_user | regression | s8 | password | public
! PUBLIC | regression | s4 | this mapping | is public
! PUBLIC | regression | t1 | modified | 1
! regress_test_role | regression | s5 | modified | 1
! regress_test_role | regression | s6 | username | test
! regress_test_role | regression | t1 | password | boo
! regress_test_role | regression | t1 | username | bob
(7 rows)
SELECT * FROM information_schema.usage_privileges WHERE object_type LIKE 'FOREIGN%' AND object_name IN ('s6', 'foo') ORDER BY 1, 2, 3, 4, 5;
grantor | grantee | object_catalog | object_schema | object_name | object_type | privilege_type | is_grantable
-------------------+-----------------------+----------------+---------------+-------------+----------------------+----------------+--------------
! foreign_data_user | foreign_data_user | regression | | foo | FOREIGN DATA WRAPPER | USAGE | YES
! foreign_data_user | foreign_data_user | regression | | s6 | FOREIGN SERVER | USAGE | YES
! foreign_data_user | regress_test_indirect | regression | | foo | FOREIGN DATA WRAPPER | USAGE | NO
! foreign_data_user | regress_test_role2 | regression | | s6 | FOREIGN SERVER | USAGE | YES
(4 rows)
SELECT * FROM information_schema.role_usage_grants WHERE object_type LIKE 'FOREIGN%' AND object_name IN ('s6', 'foo') ORDER BY 1, 2, 3, 4, 5;
grantor | grantee | object_catalog | object_schema | object_name | object_type | privilege_type | is_grantable
-------------------+-----------------------+----------------+---------------+-------------+----------------------+----------------+--------------
! foreign_data_user | foreign_data_user | regression | | foo | FOREIGN DATA WRAPPER | USAGE | YES
! foreign_data_user | foreign_data_user | regression | | s6 | FOREIGN SERVER | USAGE | YES
! foreign_data_user | regress_test_indirect | regression | | foo | FOREIGN DATA WRAPPER | USAGE | NO
! foreign_data_user | regress_test_role2 | regression | | s6 | FOREIGN SERVER | USAGE | YES
(4 rows)
SELECT * FROM information_schema.foreign_tables ORDER BY 1, 2, 3;
foreign_table_catalog | foreign_table_schema | foreign_table_name | foreign_server_catalog | foreign_server_name
-----------------------+----------------------+--------------------+------------------------+---------------------
! regression | foreign_schema | foreign_table_1 | regression | s0
(1 row)
SELECT * FROM information_schema.foreign_table_options ORDER BY 1, 2, 3, 4;
foreign_table_catalog | foreign_table_schema | foreign_table_name | option_name | option_value
-----------------------+----------------------+--------------------+-------------+--------------
! regression | foreign_schema | foreign_table_1 | be quoted | value
! regression | foreign_schema | foreign_table_1 | escape | @
! regression | foreign_schema | foreign_table_1 | quote | ~
(3 rows)
SET ROLE regress_test_role;
SELECT * FROM information_schema.user_mapping_options ORDER BY 1, 2, 3, 4;
authorization_identifier | foreign_server_catalog | foreign_server_name | option_name | option_value
--------------------------+------------------------+---------------------+-------------+--------------
! PUBLIC | regression | t1 | modified | 1
! regress_test_role | regression | s5 | modified | 1
! regress_test_role | regression | s6 | username | test
! regress_test_role | regression | t1 | password | boo
! regress_test_role | regression | t1 | username | bob
(5 rows)
SELECT * FROM information_schema.usage_privileges WHERE object_type LIKE 'FOREIGN%' AND object_name IN ('s6', 'foo') ORDER BY 1, 2, 3, 4, 5;
grantor | grantee | object_catalog | object_schema | object_name | object_type | privilege_type | is_grantable
-------------------+-----------------------+----------------+---------------+-------------+----------------------+----------------+--------------
! foreign_data_user | regress_test_indirect | regression | | foo | FOREIGN DATA WRAPPER | USAGE | NO
! foreign_data_user | regress_test_role2 | regression | | s6 | FOREIGN SERVER | USAGE | YES
(2 rows)
SELECT * FROM information_schema.role_usage_grants WHERE object_type LIKE 'FOREIGN%' AND object_name IN ('s6', 'foo') ORDER BY 1, 2, 3, 4, 5;
grantor | grantee | object_catalog | object_schema | object_name | object_type | privilege_type | is_grantable
-------------------+-----------------------+----------------+---------------+-------------+----------------------+----------------+--------------
! foreign_data_user | regress_test_indirect | regression | | foo | FOREIGN DATA WRAPPER | USAGE | NO
! foreign_data_user | regress_test_role2 | regression | | s6 | FOREIGN SERVER | USAGE | YES
(2 rows)
DROP USER MAPPING FOR current_user SERVER t1;
--- 838,957 ----
SELECT * FROM information_schema.foreign_data_wrappers ORDER BY 1, 2;
foreign_data_wrapper_catalog | foreign_data_wrapper_name | authorization_identifier | library_name | foreign_data_wrapper_language
------------------------------+---------------------------+--------------------------+--------------+-------------------------------
! foo | dummy | foreign_data_user | | c
! foo | foo | foreign_data_user | | c
! foo | postgresql | foreign_data_user | | c
(3 rows)
SELECT * FROM information_schema.foreign_data_wrapper_options ORDER BY 1, 2, 3;
foreign_data_wrapper_catalog | foreign_data_wrapper_name | option_name | option_value
------------------------------+---------------------------+--------------+--------------
! foo | foo | test wrapper | true
(1 row)
SELECT * FROM information_schema.foreign_servers ORDER BY 1, 2;
foreign_server_catalog | foreign_server_name | foreign_data_wrapper_catalog | foreign_data_wrapper_name | foreign_server_type | foreign_server_version | authorization_identifier
------------------------+---------------------+------------------------------+---------------------------+---------------------+------------------------+--------------------------
! foo | s0 | foo | dummy | | | foreign_data_user
! foo | s4 | foo | foo | oracle | | foreign_data_user
! foo | s5 | foo | foo | | 15.0 | regress_test_role
! foo | s6 | foo | foo | | 16.0 | regress_test_indirect
! foo | s8 | foo | postgresql | | | foreign_data_user
! foo | t1 | foo | foo | | | regress_test_indirect
! foo | t2 | foo | foo | | | regress_test_role
(7 rows)
SELECT * FROM information_schema.foreign_server_options ORDER BY 1, 2, 3;
foreign_server_catalog | foreign_server_name | option_name | option_value
------------------------+---------------------+-----------------+--------------
! foo | s4 | dbname | b
! foo | s4 | host | a
! foo | s6 | dbname | b
! foo | s6 | host | a
! foo | s8 | connect_timeout | 30
! foo | s8 | dbname | db1
(6 rows)
SELECT * FROM information_schema.user_mappings ORDER BY lower(authorization_identifier), 2, 3;
authorization_identifier | foreign_server_catalog | foreign_server_name
--------------------------+------------------------+---------------------
! foreign_data_user | foo | s4
! foreign_data_user | foo | s8
! PUBLIC | foo | s4
! PUBLIC | foo | s8
! PUBLIC | foo | t1
! regress_test_role | foo | s5
! regress_test_role | foo | s6
! regress_test_role | foo | t1
(8 rows)
SELECT * FROM information_schema.user_mapping_options ORDER BY lower(authorization_identifier), 2, 3, 4;
authorization_identifier | foreign_server_catalog | foreign_server_name | option_name | option_value
--------------------------+------------------------+---------------------+--------------+--------------
! foreign_data_user | foo | s8 | password | public
! PUBLIC | foo | s4 | this mapping | is public
! PUBLIC | foo | t1 | modified | 1
! regress_test_role | foo | s5 | modified | 1
! regress_test_role | foo | s6 | username | test
! regress_test_role | foo | t1 | password | boo
! regress_test_role | foo | t1 | username | bob
(7 rows)
SELECT * FROM information_schema.usage_privileges WHERE object_type LIKE 'FOREIGN%' AND object_name IN ('s6', 'foo') ORDER BY 1, 2, 3, 4, 5;
grantor | grantee | object_catalog | object_schema | object_name | object_type | privilege_type | is_grantable
-------------------+-----------------------+----------------+---------------+-------------+----------------------+----------------+--------------
! foreign_data_user | foreign_data_user | foo | | foo | FOREIGN DATA WRAPPER | USAGE | YES
! foreign_data_user | foreign_data_user | foo | | s6 | FOREIGN SERVER | USAGE | YES
! foreign_data_user | regress_test_indirect | foo | | foo | FOREIGN DATA WRAPPER | USAGE | NO
! foreign_data_user | regress_test_role2 | foo | | s6 | FOREIGN SERVER | USAGE | YES
(4 rows)
SELECT * FROM information_schema.role_usage_grants WHERE object_type LIKE 'FOREIGN%' AND object_name IN ('s6', 'foo') ORDER BY 1, 2, 3, 4, 5;
grantor | grantee | object_catalog | object_schema | object_name | object_type | privilege_type | is_grantable
-------------------+-----------------------+----------------+---------------+-------------+----------------------+----------------+--------------
! foreign_data_user | foreign_data_user | foo | | foo | FOREIGN DATA WRAPPER | USAGE | YES
! foreign_data_user | foreign_data_user | foo | | s6 | FOREIGN SERVER | USAGE | YES
! foreign_data_user | regress_test_indirect | foo | | foo | FOREIGN DATA WRAPPER | USAGE | NO
! foreign_data_user | regress_test_role2 | foo | | s6 | FOREIGN SERVER | USAGE | YES
(4 rows)
SELECT * FROM information_schema.foreign_tables ORDER BY 1, 2, 3;
foreign_table_catalog | foreign_table_schema | foreign_table_name | foreign_server_catalog | foreign_server_name
-----------------------+----------------------+--------------------+------------------------+---------------------
! foo | foreign_schema | foreign_table_1 | foo | s0
(1 row)
SELECT * FROM information_schema.foreign_table_options ORDER BY 1, 2, 3, 4;
foreign_table_catalog | foreign_table_schema | foreign_table_name | option_name | option_value
-----------------------+----------------------+--------------------+-------------+--------------
! foo | foreign_schema | foreign_table_1 | be quoted | value
! foo | foreign_schema | foreign_table_1 | escape | @
! foo | foreign_schema | foreign_table_1 | quote | ~
(3 rows)
SET ROLE regress_test_role;
SELECT * FROM information_schema.user_mapping_options ORDER BY 1, 2, 3, 4;
authorization_identifier | foreign_server_catalog | foreign_server_name | option_name | option_value
--------------------------+------------------------+---------------------+-------------+--------------
! PUBLIC | foo | t1 | modified | 1
! regress_test_role | foo | s5 | modified | 1
! regress_test_role | foo | s6 | username | test
! regress_test_role | foo | t1 | password | boo
! regress_test_role | foo | t1 | username | bob
(5 rows)
SELECT * FROM information_schema.usage_privileges WHERE object_type LIKE 'FOREIGN%' AND object_name IN ('s6', 'foo') ORDER BY 1, 2, 3, 4, 5;
grantor | grantee | object_catalog | object_schema | object_name | object_type | privilege_type | is_grantable
-------------------+-----------------------+----------------+---------------+-------------+----------------------+----------------+--------------
! foreign_data_user | regress_test_indirect | foo | | foo | FOREIGN DATA WRAPPER | USAGE | NO
! foreign_data_user | regress_test_role2 | foo | | s6 | FOREIGN SERVER | USAGE | YES
(2 rows)
SELECT * FROM information_schema.role_usage_grants WHERE object_type LIKE 'FOREIGN%' AND object_name IN ('s6', 'foo') ORDER BY 1, 2, 3, 4, 5;
grantor | grantee | object_catalog | object_schema | object_name | object_type | privilege_type | is_grantable
-------------------+-----------------------+----------------+---------------+-------------+----------------------+----------------+--------------
! foreign_data_user | regress_test_indirect | foo | | foo | FOREIGN DATA WRAPPER | USAGE | NO
! foreign_data_user | regress_test_role2 | foo | | s6 | FOREIGN SERVER | USAGE | YES
(2 rows)
DROP USER MAPPING FOR current_user SERVER t1;
***************
*** 959,965 ****
SELECT * FROM information_schema.user_mapping_options ORDER BY 1, 2, 3, 4;
authorization_identifier | foreign_server_catalog | foreign_server_name | option_name | option_value
--------------------------+------------------------+---------------------+-------------+--------------
! regress_test_role | regression | s6 | username |
(1 row)
RESET ROLE;
--- 959,965 ----
SELECT * FROM information_schema.user_mapping_options ORDER BY 1, 2, 3, 4;
authorization_identifier | foreign_server_catalog | foreign_server_name | option_name | option_value
--------------------------+------------------------+---------------------+-------------+--------------
! regress_test_role | foo | s6 | username |
(1 row)
RESET ROLE;
======================================================================
*** /home/ioltas/make/postgres/src/test/regress/expected/sequence.out Thu Dec 5 03:45:03 2013
--- /home/ioltas/make/postgres/src/test/regress/results/sequence.out Thu Dec 5 04:08:33 2013
***************
*** 305,316 ****
ORDER BY sequence_name ASC;
sequence_catalog | sequence_schema | sequence_name | data_type | numeric_precision | numeric_precision_radix | numeric_scale | start_value | minimum_value | maximum_value | increment | cycle_option
------------------+-----------------+--------------------+-----------+-------------------+-------------------------+---------------+-------------+---------------+---------------------+-----------+--------------
! regression | public | sequence_test2 | bigint | 64 | 2 | 0 | 32 | 5 | 36 | 4 | YES
! regression | public | serialtest2_f2_seq | bigint | 64 | 2 | 0 | 1 | 1 | 9223372036854775807 | 1 | NO
! regression | public | serialtest2_f3_seq | bigint | 64 | 2 | 0 | 1 | 1 | 9223372036854775807 | 1 | NO
! regression | public | serialtest2_f4_seq | bigint | 64 | 2 | 0 | 1 | 1 | 9223372036854775807 | 1 | NO
! regression | public | serialtest2_f5_seq | bigint | 64 | 2 | 0 | 1 | 1 | 9223372036854775807 | 1 | NO
! regression | public | serialtest2_f6_seq | bigint | 64 | 2 | 0 | 1 | 1 | 9223372036854775807 | 1 | NO
(6 rows)
-- Test comments
--- 305,316 ----
ORDER BY sequence_name ASC;
sequence_catalog | sequence_schema | sequence_name | data_type | numeric_precision | numeric_precision_radix | numeric_scale | start_value | minimum_value | maximum_value | increment | cycle_option
------------------+-----------------+--------------------+-----------+-------------------+-------------------------+---------------+-------------+---------------+---------------------+-----------+--------------
! foo | public | sequence_test2 | bigint | 64 | 2 | 0 | 32 | 5 | 36 | 4 | YES
! foo | public | serialtest2_f2_seq | bigint | 64 | 2 | 0 | 1 | 1 | 9223372036854775807 | 1 | NO
! foo | public | serialtest2_f3_seq | bigint | 64 | 2 | 0 | 1 | 1 | 9223372036854775807 | 1 | NO
! foo | public | serialtest2_f4_seq | bigint | 64 | 2 | 0 | 1 | 1 | 9223372036854775807 | 1 | NO
! foo | public | serialtest2_f5_seq | bigint | 64 | 2 | 0 | 1 | 1 | 9223372036854775807 | 1 | NO
! foo | public | serialtest2_f6_seq | bigint | 64 | 2 | 0 | 1 | 1 | 9223372036854775807 | 1 | NO
(6 rows)
-- Test comments
***************
*** 387,393 ****
ORDER BY sequence_name ASC;
sequence_catalog | sequence_schema | sequence_name | data_type | numeric_precision | numeric_precision_radix | numeric_scale | start_value | minimum_value | maximum_value | increment | cycle_option
------------------+-----------------+----------------+-----------+-------------------+-------------------------+---------------+-------------+---------------+---------------+-----------+--------------
! regression | public | sequence_test2 | bigint | 64 | 2 | 0 | 32 | 5 | 36 | 4 | YES
(1 row)
DROP USER seq_user;
--- 387,393 ----
ORDER BY sequence_name ASC;
sequence_catalog | sequence_schema | sequence_name | data_type | numeric_precision | numeric_precision_radix | numeric_scale | start_value | minimum_value | maximum_value | increment | cycle_option
------------------+-----------------+----------------+-----------+-------------------+-------------------------+---------------+-------------+---------------+---------------+-----------+--------------
! foo | public | sequence_test2 | bigint | 64 | 2 | 0 | 32 | 5 | 36 | 4 | YES
(1 row)
DROP USER seq_user;
======================================================================
On Thu, Dec 5, 2013 at 5:12 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
Those tests are failing because some relations of information_schemas
contain information that are database-dependent.
I forgot to mention that it is our QE team at VMware that reported me
a portion of this failure, and I just had to dig a little bit to find
the root cause. And for the curious people: yes, we run regressions on
customized database names.
Regards,
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Michael Paquier <michael.paquier@gmail.com> writes:
It happens that the following regression tests are failing if they are
run on a database not named "regression":
This does not seem like a bug to me, although maybe we'd better update the
documentation to specify that you need to use a DB named regression.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, Dec 5, 2013 at 9:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Michael Paquier <michael.paquier@gmail.com> writes:
It happens that the following regression tests are failing if they are
run on a database not named "regression":This does not seem like a bug to me, although maybe we'd better update the
documentation to specify that you need to use a DB named regression.
At the same thing, supporting it might not cost anything.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
On Thu, Dec 5, 2013 at 9:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Michael Paquier <michael.paquier@gmail.com> writes:
It happens that the following regression tests are failing if they are
run on a database not named "regression":
This does not seem like a bug to me, although maybe we'd better update the
documentation to specify that you need to use a DB named regression.
At the same thing, supporting it might not cost anything.
Well, changing these specific tests today might not be terribly expensive,
but what is it that prevents more such tests from being committed next
week? Perhaps by somebody who feels current_database() should be included
in code coverage, for example?
More generally, we never have and never can promise that the regression
tests pass regardless of environment. If you turn off enable_seqscan,
for instance, you'll get a whole lot of not-terribly-exciting diffs.
I see no particular benefit to promising that the name of the regression
database isn't significant.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2013/12/06, at 3:52, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
On Thu, Dec 5, 2013 at 9:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Michael Paquier <michael.paquier@gmail.com> writes:It happens that the following regression tests are failing if they are
run on a database not named "regression":This does not seem like a bug to me, although maybe we'd better update the
documentation to specify that you need to use a DB named regression.At the same thing, supporting it might not cost anything.
Well, changing these specific tests today might not be terribly expensive,
but what is it that prevents more such tests from being committed next
week? Perhaps by somebody who feels current_database() should be included
in code coverage, for example?More generally, we never have and never can promise that the regression
tests pass regardless of environment. If you turn off enable_seqscan,
for instance, you'll get a whole lot of not-terribly-exciting diffs.
I see no particular benefit to promising that the name of the regression
database isn't significant.
You got a point here. Classifying that as a "don't do that" in the documentation is fine for me as well, as I recall that --dbname has been added to pg_regress only for contrib regression support.
Regards,
--
Michael
(Sent from my mobile phone)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Thu, 2013-12-05 at 17:12 +0900, Michael Paquier wrote:
IMHO, the regression test suite would gain in consistency and
portability if we do not refer to data that is database-dependent.
I once did some similar fixes (e3d9dceef62e072cf9a433ae6c74a1c5a10d94d3)
but then didn't pursue it any longer, because it would restrict what we
could actually test. I don't remember what I was trying to do there,
but why do you need to run the tests in a different database?
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Dec 6, 2013 at 12:02 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
On Thu, 2013-12-05 at 17:12 +0900, Michael Paquier wrote:
IMHO, the regression test suite would gain in consistency and
portability if we do not refer to data that is database-dependent.I once did some similar fixes (e3d9dceef62e072cf9a433ae6c74a1c5a10d94d3)
but then didn't pursue it any longer, because it would restrict what we
could actually test. I don't remember what I was trying to do there,
but why do you need to run the tests in a different database?
I don't know, but by looking at this test code I could guess that
using a custom database name (that also changed depending on the
environment used) made errors easier to track. So, I just went ahead,
cleaned up our code to use "regression" and made things a bit smarter
for the environment information.
For the documentation patch, I propose the attached to avoid future
confusions. Comments? It might make sense to back-patch as well.
Also... An advice for the archives and other people here: never update
test output dynamically and use the existing ones. I wouldn't even
recommend adding new outputs to the existing tests except if you want
to make your maintenance a pain as you would need to track new tests
and update accordingly. Even better, submit patches if new outputs
make sense, or write new tests and break things independently as much
as you want.
--
Michael
Attachments:
20131206_doc_regress_restriction.patchtext/x-diff; charset=US-ASCII; name=20131206_doc_regress_restriction.patchDownload
commit 0e40cb47189062433b99c1e33e75a096c7c97dd8
Author: Michael Paquier <michael@otacoo.com>
Date: Fri Dec 6 13:13:23 2013 +0900
Addition of in-core test suite restrictions in documentation
Mention in the documentation of regression tests limitations related to
the database where tests are run as well as possible inconsistencies
for server parameters.
diff --git a/doc/src/sgml/regress.sgml b/doc/src/sgml/regress.sgml
index 2b95587..719210b 100644
--- a/doc/src/sgml/regress.sgml
+++ b/doc/src/sgml/regress.sgml
@@ -257,6 +257,24 @@ gmake check EXTRA_TESTS=collate.linux.utf8 LANG=en_US.utf8
platforms, and only when run in a database that uses UTF-8 encoding.
</para>
</sect2>
+
+ <sect2>
+ <title>Restrictions</title>
+
+ <para>
+ Regression tests should be run on a database named <literal>regression</>
+ to prevent failures of tests using directly or indirectly the current
+ database name in output results. <literal>regression</> is the default
+ database name for tests on core, and contrib modules use
+ <literal>contrib_regression</> as default.
+ </para>
+
+ <para>
+ Parameters able to change the output of queries like enable/disable flags
+ described in <xref linkend="runtime-config-query-enable"> for
+ <command>EXPLAIN</> should use default values as well.
+ </para>
+ </sect2>
</sect1>
<sect1 id="regress-evaluation">
Hi,
For the documentation patch, I propose the attached to avoid future
confusions. Comments? It might make sense to back-patch as well.
Compiles, didn't find any typos and I think it is comprehensible.
Looks fine for me.
Best regards,
--
Christian Kruse http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
On Thu, Jan 30, 2014 at 3:32 AM, Christian Kruse
<christian@2ndquadrant.com> wrote:
For the documentation patch, I propose the attached to avoid future
confusions. Comments? It might make sense to back-patch as well.Compiles, didn't find any typos and I think it is comprehensible.
I took a look at this with a view to committing it but on examination
I'm not sure this is the best way to proceed. The proposed text
documents that the tests should be run in a database called
regression, but the larger documentation chapter of which this section
is a part never explains how to run them anywhere else, so it feels a
bit like telling a ten-year-old not to burn out the clutch.
The bit about not changing enable_* probably belongs, if anywhere, in
section 30.2, on test evaluation, rather than here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jan 31, 2014 at 6:09 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Thu, Jan 30, 2014 at 3:32 AM, Christian Kruse
<christian@2ndquadrant.com> wrote:For the documentation patch, I propose the attached to avoid future
confusions. Comments? It might make sense to back-patch as well.Compiles, didn't find any typos and I think it is comprehensible.
I took a look at this with a view to committing it but on examination
I'm not sure this is the best way to proceed. The proposed text
documents that the tests should be run in a database called
regression, but the larger documentation chapter of which this section
is a part never explains how to run them anywhere else, so it feels a
bit like telling a ten-year-old not to burn out the clutch.The bit about not changing enable_* probably belongs, if anywhere, in
section 30.2, on test evaluation, rather than here.
And what about the attached? I have moved all the content to 30.2, and
added two paragraphs: one about the planner flags, the other about the
database used.
Regards,
--
Michael
Attachments:
20140131_doc_regress_restriction_v2.patchtext/x-diff; charset=US-ASCII; name=20140131_doc_regress_restriction_v2.patchDownload
*** a/doc/src/sgml/regress.sgml
--- b/doc/src/sgml/regress.sgml
***************
*** 471,476 **** diff results/random.out expected/random.out
--- 471,510 ----
not worry unless the random test fails repeatedly.
</para>
</sect2>
+
+ <sect2>
+ <title>Planner Configuration parameters</title>
+
+ <para>
+ Parameters able to change the planning of queries like enable/disable
+ flags described in <xref linkend="runtime-config-query-enable"> for
+ <command>EXPLAIN</> should use default values.
+ </para>
+ </sect2>
+
+ <sect2>
+ <title>Database Name</title>
+
+ <para>
+ Regression tests should be run on a database named <literal>regression</>
+ to prevent failures of tests using directly or indirectly the current
+ database name in output results. The tests that would fail in this case
+ include <literal>updatable_views</literal>, <literal>foreign_data</literal>,
+ <literal>xml_map</literal> and <literal>sequence</literal>.
+ </para>
+
+ <para>
+ <literal>regression</> is the default database name for tests of core,
+ and contrib modules use <literal>contrib_regression</> as default.
+ </para>
+
+ <para>
+ Running regression tests with <application>pg_regress</application>
+ causes the existed database to be dropped before running the tests,
+ so be sure that there is not already a database with the same name
+ existing on server before running it.
+ </para>
+ </sect2>
</sect1>
<!-- We might want to move the following section into the developer's guide. -->
On Fri, Jan 31, 2014 at 2:28 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
I took a look at this with a view to committing it but on examination
I'm not sure this is the best way to proceed. The proposed text
documents that the tests should be run in a database called
regression, but the larger documentation chapter of which this section
is a part never explains how to run them anywhere else, so it feels a
bit like telling a ten-year-old not to burn out the clutch.The bit about not changing enable_* probably belongs, if anywhere, in
section 30.2, on test evaluation, rather than here.And what about the attached? I have moved all the content to 30.2, and
added two paragraphs: one about the planner flags, the other about the
database used.
Regards,
Well, it doesn't really address my first concern, which was that you
talk about running the tests in a database named regression, but
that's exactly what "make check" does and it's unclear how you would
do anything else without modifying the source code. It's not the
purpose of the documentation to tell you all the ways that you could
break things if you patch the tree. I also don't want to document
exactly which tests would fail if you did hack things like that; that
documentation is likely to become outdated.
I think the remaining points you raise are worth mentioning. I'm
attaching a patch with my proposed rewording of your changes. I made
the section about configuration parameters a bit more generic and
adjusted the phrasing to sound more natural in English, and I moved
your mention of the other issues around a bit. What do you think of
this version?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Attachments:
regressdoc.patchtext/x-patch; charset=US-ASCII; name=regressdoc.patchDownload
diff --git a/doc/src/sgml/regress.sgml b/doc/src/sgml/regress.sgml
index 2b95587..edb476a 100644
--- a/doc/src/sgml/regress.sgml
+++ b/doc/src/sgml/regress.sgml
@@ -125,7 +125,9 @@ gmake installcheck-parallel
</screen>
The tests will expect to contact the server at the local host and the
default port number, unless directed otherwise by <envar>PGHOST</envar> and
- <envar>PGPORT</envar> environment variables.
+ <envar>PGPORT</envar> environment variables. The tests will be run in a
+ database named <literal>regression</>; any existing database by this name
+ will be dropped.
</para>
<para>
@@ -147,7 +149,9 @@ gmake installcheck
</screen>
The <filename>contrib</> modules must have been built and installed first.
You can also do this in a subdirectory of <filename>contrib</> to run
- the tests for just one module.
+ the tests for just one module. Tests of <literal>contrib</> modules will
+ be run in a database named <literal>contrib_regression</>; any existing
+ database by this name will be dropped.
</para>
</sect2>
@@ -471,6 +475,18 @@ diff results/random.out expected/random.out
not worry unless the random test fails repeatedly.
</para>
</sect2>
+
+ <sect2>
+ <title>Configuration Parameters</title>
+
+ <para>
+ When running the tests against an existing installation, some non-default
+ parameter settings could cause the tests to fail. For example, the
+ settings described in <xref linkend="runtime-config-query-enable">
+ could cause plan changes that would affect the results of tests which
+ use <command>EXPLAIN</>.
+ </para>
+ </sect2>
</sect1>
<!-- We might want to move the following section into the developer's guide. -->
On Sat, Feb 1, 2014 at 12:42 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Fri, Jan 31, 2014 at 2:28 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:I took a look at this with a view to committing it but on examination
I'm not sure this is the best way to proceed. The proposed text
documents that the tests should be run in a database called
regression, but the larger documentation chapter of which this section
is a part never explains how to run them anywhere else, so it feels a
bit like telling a ten-year-old not to burn out the clutch.The bit about not changing enable_* probably belongs, if anywhere, in
section 30.2, on test evaluation, rather than here.And what about the attached? I have moved all the content to 30.2, and
added two paragraphs: one about the planner flags, the other about the
database used.
Regards,Well, it doesn't really address my first concern, which was that you
talk about running the tests in a database named regression, but
that's exactly what "make check" does and it's unclear how you would
do anything else without modifying the source code. It's not the
purpose of the documentation to tell you all the ways that you could
break things if you patch the tree. I also don't want to document
exactly which tests would fail if you did hack things like that; that
documentation is likely to become outdated.I think the remaining points you raise are worth mentioning. I'm
attaching a patch with my proposed rewording of your changes. I made
the section about configuration parameters a bit more generic and
adjusted the phrasing to sound more natural in English, and I moved
your mention of the other issues around a bit. What do you think of
this version?
The part about the planning parameter looks good, thanks. The places
used to mention the databases used also makes more sense. Thanks for
your input.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Jan 31, 2014 at 5:48 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
On Sat, Feb 1, 2014 at 12:42 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Fri, Jan 31, 2014 at 2:28 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:I took a look at this with a view to committing it but on examination
I'm not sure this is the best way to proceed. The proposed text
documents that the tests should be run in a database called
regression, but the larger documentation chapter of which this section
is a part never explains how to run them anywhere else, so it feels a
bit like telling a ten-year-old not to burn out the clutch.The bit about not changing enable_* probably belongs, if anywhere, in
section 30.2, on test evaluation, rather than here.And what about the attached? I have moved all the content to 30.2, and
added two paragraphs: one about the planner flags, the other about the
database used.
Regards,Well, it doesn't really address my first concern, which was that you
talk about running the tests in a database named regression, but
that's exactly what "make check" does and it's unclear how you would
do anything else without modifying the source code. It's not the
purpose of the documentation to tell you all the ways that you could
break things if you patch the tree. I also don't want to document
exactly which tests would fail if you did hack things like that; that
documentation is likely to become outdated.I think the remaining points you raise are worth mentioning. I'm
attaching a patch with my proposed rewording of your changes. I made
the section about configuration parameters a bit more generic and
adjusted the phrasing to sound more natural in English, and I moved
your mention of the other issues around a bit. What do you think of
this version?The part about the planning parameter looks good, thanks. The places
used to mention the databases used also makes more sense. Thanks for
your input.
OK, committed and back-patched to 9.3.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Tue, Feb 4, 2014 at 12:49 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Fri, Jan 31, 2014 at 5:48 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:The part about the planning parameter looks good, thanks. The places
used to mention the databases used also makes more sense. Thanks for
your input.OK, committed and back-patched to 9.3.
Thanks.
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers