- 03 3月, 2017 7 次提交
-
-
由 Heikki Linnakangas 提交于
This test case tests that a CTE query from earlier in the test file also works if it's put in a view. There are a few other tests for CTEs in views in there, and this query doesn't seem particularly interesting from the point of view of testing views. There's usually little harm in a little excessive test queries, but this query is exceptionally slow. Removing it reduces the runtime of this test by about 5-10 seconds on my laptop.
-
由 Heikki Linnakangas 提交于
If the EXPLAIN is on separate line, the mechansim in atmsort.pm to detect EXPLAIN queries, and to mask out trivial differences like different costs, doesn't recognize it. This caused a failure, for example if you set "optimizer=off" explicitly in postgresql.conf, because that added a Settings line to the explain output. We rely on atmsort.pm to mask out trivial differences like that.
-
由 Heikki Linnakangas 提交于
Serial and bigserial are just aliases for int4 and int8, respectively, with a DEFAULT (nextval(seq)). The boundary tests are there for redundant with the boundary tests on int8, in the 'int8' test in the main suite, and the 'dml_serial' is redundant with the tests on serial datatype in the 'sequence' test in the main suite.
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
Once upon a time, these UPDATEs used to give a "Append-only tables are not updatable" error. But these days, they are updateable, and we have plenty of tests for updating append-only tables. Remove this test as obsolete or redundant
-
由 Ashwin Agrawal 提交于
-
- 02 3月, 2017 19 次提交
-
-
由 Heikki Linnakangas 提交于
We have good coverage of this in the 'analyze' test in the main test suite now.
-
由 Heikki Linnakangas 提交于
REINDEX grabs a ShareLock on the table relation very early on, and TRUNCATE grabs an AccessExclusiveLock very early on. If we trust that the lock manager isn't broken, there's no need to test this combination of commands in particular. (For testing the lock manager, these tests give only very narrow coverage.) Furthermore, all these test cases are effectively the same, as it it makes no difference what kind of a table or what kind of an index it is, the locking works the same for all. ALTER and DROP TABLE also grab an AccessExclusiveLock on the table, which conflicts with the ShareLock that REINDEX takes. It works the same with all flavors of ALTER and DROP TABLE, and with all kinds of tables, and all kinds of indexes.
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
This was mostly already in bfv_partition. For completeness, move the code from the TINC test to bfv_partition to also execute the query, not just EXPLAIN it.
-
由 Heikki Linnakangas 提交于
There's a test in the main suite's 'partition' test for this already, with the 'deep_part' test table.
-
由 Heikki Linnakangas 提交于
There is already a similar test in the 'partition' test in the main test suite. Search for "-- Sub-partition insertion" in partition.sql to find it.
-
由 Heikki Linnakangas 提交于
It's not allowed. We already have tests for both CREATE TABLE and ALTER TABLE ADD PARTITION, with "WITH OIDS=false", in the 'partition' test of the main test suite.
-
由 Heikki Linnakangas 提交于
Rename the test tables in 'partition' test, so that they don't clash with the test tables in 'partition1' test. Change a few validation queries to not get confused if there are unrelated tables with partitions in the database. With these changes, we can run 'partition' and 'partition1' in the same parallel group, which is a more logical grouping.
-
由 Heikki Linnakangas 提交于
All of these tests used the same test table, but it was dropped and re-created for each test. To speed things up, create it once, and wrap each test in a begin-rollback block. The access plan of one of the tests varied depending on optimizer_segments, and it caused a difference in the ERROR message. The TINC tests were always run with 2 segments, but you got a different plan and message with 3 or more segments. Added a "SET optimizer_segments=2" to stabilize that, and a comment explaining the situation.
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
The transformation of "NOT IN" or "= ALL" incorrectly added a condition that the outer side of the join must not be NULL. But that's not true, when the other side is an empty set. Discovered while moving old TINC tests to the main test suite. The 'lasj_hash_all_3' test exposed this issue, when run with ORCA disabled. This has apparently gone unnoticed, because no-one has run those tests without ORCA. There were also incorrect query results memorized, for tests 'lasj_notin_multiple_3' and 'lasj_hash_notin_multiple_3'. They are similar queries, but because ORCA falls back to the planner for them, we had memorized the Planner results for them, and hadn't noticed that the results were in fact incorrect. Fixes github issue #1907.
-
由 Heikki Linnakangas 提交于
We have a bunch of tests on subpartitioned tables in the main suite, e.g. in the 'partition' and 'bfv_partition' tests. And these tests were marked with "@skip", anyway, so they were not run by TINC either.
-
由 Heikki Linnakangas 提交于
I moved them to the 'partition_pruning_with_fn' test, but because there is no functions involved in these tests, I renamed the test to just 'partition_pruning'. There is possibly some overlap with these new tests and the existing ones in the same file, but will let future test archeologists to decide that. These are cheap tests, in any case.
-
由 Heikki Linnakangas 提交于
The storage_persistent_filerep_accessmethods_and_vacuum task contained two filerep tests: FilerepResync.test_filerep_resysnc ... 585576.51 ms ... ok FilerepProcArrayRemoveTestCase.test_verify_ct_after_procarray_removal ... 136553.63 ms ... ok Move them together with the filerep_end_to_end_xlog_ctlog_cons task, so that all the filerep tests are in the same task. To reflect that, rename the 'filerep_end_to_end_xlog_ctlog_cons task' to just 'filerep'. The 'storage_persistent_filerep_accessmethods_and_vacuum' task was the slowest task among the parallel tasks in the job, so moving the two filerep tests elsewhere should reduce overall runtime of the storage job.
-
由 Heikki Linnakangas 提交于
These are already covered by the 'appendonly' and 'uao_dml/uao_dml' tests in the main test suite.
-
由 Heikki Linnakangas 提交于
"int" and "int4" are the same datatype. They are mapped to the same early on, in the parsing stage. For those tests that have been duplicated for many different datatypes, remove the _int_ variant, leaving just the _int4_ variant.
-
由 Heikki Linnakangas 提交于
We have sufficient coverage for these in the 'geometry' test in the main test suite. There are no UPDATEs in 'geometry', but that seems uninteresting; there is no reason to believe that UPDATE on these types would behave differently from an UPDATE on any other type. The test descriptions were misleading, BTW. These are not "boundary" tests, the values used are not close to the min or max values the data types can represent.
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
* Move all the udf_insert_* tests to the main suite. * Move 'volatilefn_dml_int8' test to the main suite. * Remove all the other volatilefn_dml_* tests. There's no reason to believe that the data types used in the table would make a difference, so keeping one variant of this is enough.
-
- 01 3月, 2017 9 次提交
-
-
由 Ning Yu 提交于
Add view gp_toolkit.gp_resgroup_status for resource group runtime statistics information, such as cpu usage, memory usage, etc.. Example: -- query resource group runtime statistics information SELECT * FROM gp_toolkit.gp_resgroup_status; A helper function pg_resgroup_get_status_kv() is also provided to collect these information. A new dir src/backend/utils/resgroup/ is created to hold the resgroup source code. As resgroup is not fully implemented yet there is only dummy output for this view at the moment.
-
由 Ning Yu 提交于
Add view gp_toolkit.gp_resgroup_config for resource group information, such as concurrency, cpu rate limitation, etc.. Example: -- query resource group config information SELECT * FROM gp_toolkit.gp_resgroup_config;
-
由 Heikki Linnakangas 提交于
I'm not how many of these tests are worth keeping at all, but as a first step, let's get them into the main test suite. The runtime of the parallel group with these tests is about 1 minute on my laptop. This is mostly a straightforward move, with mechanical changes removing the useless TINC tags. However, some tests were marked with the special "@executemode ORCA_PLANNER_DIFF" tag. The code in __init__.py ran those tests differently. Normally, you run a test, and comparet the output with the expected output file. But those ORCA_PLANNER_DIFF tests were run twice, with and without ORCA, and the results were compared against each other, instead of the expected output stored in the repository. The expected outputs of those tests were out of date, you got a different error message now than what was remembered in the expected output. Now those tests are run as normal pg_regress tests. I updated the expected output of those tests to match what you get nowadays.
-
由 Heikki Linnakangas 提交于
pg_size_pretty() is completely ordinary and boring function. It doesn't do database access or anything like that. We can live without testing it in every possible context.
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
* dml_boundary_bool seems redundant. We surely have a lot of other tests involving boolean columns. * dml_boundary_char is redundant with the 'char' test in main suite. * dml_boundary_money was disabled. * dml_boundary_smallint was redundant with 'int2' test in main suite. * dml_boundary_integer was redundant with 'int4' test in main suite. * dml_boundary_bigint was redundant with 'int8' test in main suite.
-
由 Heikki Linnakangas 提交于
There are a lot of similar and more interesting tests for direct dispatch in the main test suite ('direct_dispatch' test, for example). The negative test cases, like inserting into a randomly distributed table so that direct dispatch is not possible, were not very interesting, so I removed them. A mistake in the other direction, i.e. not performing direct dispatch when we could have, does not lead to incorrect query results, just slower performance, which is why we need bespoken tests for those. But if we erroneously do direct dispatch for a query, where it is not legal, that will lead to incorrect query results, so we should catch those cases by all the other tests in the test suite. There was one test case, involving DEFAULTs in the INSERT statement, that I thought is marginally worth keeping, so added a case for that in 'direct_dispatch' before removing it.
-
由 Shreedhar Hardikar 提交于
-
由 Heikki Linnakangas 提交于
We have sufficient coverage for these in the main regression suite already. * Partitions are covered by the 'partindex_test', 'partition', and 'partition1' tests. * ALTER TABLE on non-partitioned tests are covered in 'alter_table' test. * SET DISTRIBUTION POLICY is covered by the 'alter_distribution_policy' test. It seems unnecessary test so many different data types, there is no datatype-specific handling in the set distribution policy code.
-
- 28 2月, 2017 5 次提交
-
-
The need for heap access methods before xlog replay is removed by commit e2d6aa1481f6cdbd846d4b17b68eb4387dae9211. This commit simply moves the relcache initialization to pass4, where it is really needed. Do not bother to remove relcache init file at the end of crash recovery pass2. Error out if relation cache initialized at wrong time.
-
由 Daniel Gustafsson 提交于
The error messages are developer or debug facing, no reason to believe this will break anyones regexing of logfiles in prod.
-
由 khannaekta 提交于
* Update regex to reflect output change [#140454709] `pg_lock_status` changed output format.
-
由 Jesse Zhang 提交于
We cannot assume we are running in a special environment that is always in -8 time zone without DST. Making such setting explicit to make tests portable. Unskipping test as they will succeed now.
-
由 Bhuvnesh Chaudhary 提交于
-