- 23 2月, 2017 1 次提交
-
-
由 Heikki Linnakangas 提交于
The test disconnects, and immediately reconnects and checks that temp table from the previous session has been removed. However, the old backend removes the tables only after the disconnection, so there's a race condition here: the new session might query pg_tables and still see the table, if the old session was not fast enough to remove it first. Add a two-second sleep, to make the race condition less likely to happen. This is not guaranteed to avoid the race altogether, but I don't see an easy way to wait for the specific event that the old backend has exited. A sleep in a test that doesn't run in parallel with other tests is a bit annoying, as it directly makes the whole regression suite slower. To compensate for that, move the test to run in parallel with the other nearby bfv_* tests. Those other tests don't use temp tables, so it still works. Also, modify the validation query in the test that checks that there are no temp tables, to return whole rows, not just COUNT(*). That'll make analyzing easier, if this test fails.
-
- 22 2月, 2017 8 次提交
-
-
由 Heikki Linnakangas 提交于
I removed these tests in commit 1398c14e, but forgot to remove it from this Makefile.
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
The uao_dml and uaocs_dml tests were identical, except that there were a few additional queries in the uao_dml suite that were missing from the uaocs_dml suite, and various cosmetic differences in table names and such. Use the new "uao templating" mechanism in pg_regress to generate both cases from a single set of files. I didn't look for redundant or useless tests in these suites. At a quick glance, at least many of the select tests seem quite pointless, so it would be good to cull these in the future.
-
由 Heikki Linnakangas 提交于
This is a straightforward copy-paste, except for thing: I changed all the quicklz-compressed tables to use zlib instead, so that these tests work without support for legacy quicklz compression. AFAICT, the compression isn't a very interesting aspect for these tests (I even considered making them uncompressed.)
-
由 Heikki Linnakangas 提交于
These test queries were copy-pasted from the upstream test at src/pl/plperl/plperl_trigger.sql, so nothing interesting there. The test harness would try to install plperl with gppkg, but I don't think that's very interesting to test. AFAIK we don't plan to install plperl.so with the gppkg mechanism anymore. And if we do, the tests for that should live next to the gppkg scripts to create the package, not here. test_spi.py referenced query01.sql, query02.sql and query03.sql, but the directory only contained query01.sql and query03.sql. Therefore, I believe this was actually broken as it is.
-
由 Heikki Linnakangas 提交于
We have more comprehensive tests for gpcheckcat in gpMgmt/test/behave/mgmt_utils/gpcheckcat.feature, and in gpMgmt/bin/gppylib/test/unit/test_unit_gpcheckcat.py.
-
由 Adam Lee 提交于
Due to changes of external table "on master" feature Signed-off-by: NHaozhou Wang <hawang@pivotal.io>
-
由 Heikki Linnakangas 提交于
I typoed the INSERT command in this test, and even checked in the ERROR in the expected output. Fix. Also, make test case a bit less fragile, by advancing the XID counter also after the INSERT+DELETEs in the second part of these tests. This ensures that the tables will look 'old' before the vacuum. Tweak the limits of 'old' and 'young' XID, to make more sure that a table just created is considered 'young', and that advancing the XID counter pushes the age to 'old' on all segments.
-
- 21 2月, 2017 14 次提交
-
-
由 Heikki Linnakangas 提交于
I'm not sure why this seemed to pass on my laptop without this file, but looking at the code, I'm pretty sure it's still needed for the test_uao_crash_update_with_ins_fault test. We'll see what the Concourse job thinks..
-
由 Heikki Linnakangas 提交于
These tests test for an old bug, where vacuuming an empty AO relation would not advance its relfrozenxid. Doesn't seem very likely for that particular bug to reappear, but seems like a good idea to have some coverage for freezing and relfrozenxid advancement. In this rewritten form, these tests are fairly quick, too (1-2 seconds on my laptop).
-
由 Heikki Linnakangas 提交于
Turns out that the remaining tests need both uao_crash_update2.sql, and uaocs_crash_update2.sql. [me puts on brown paper back]
-
由 Heikki Linnakangas 提交于
The remaining tests needed uaocs_crash_update2.sql, not uao_crash_update2.sql
-
由 Heikki Linnakangas 提交于
I removed these files in commit b39c1356, but it turns out that some of the remaining tests still used those files.
-
由 Heikki Linnakangas 提交于
The pattern in these tests was: 1. Create and populate a test append-only table 2. Induce a fault with gpfaultinjector, to crash the server at beginning of appendonly_insert/update/delete function. 3. Try to INSERT, UPDATE or DELETE some rows, crashing the server. Crashing the server at the beginning of the operation isn't very interesting, because we haven't done any on-disk modifications at that point yet. There is no reason to believe that there would be a problem at crash recovery at that point. In particular, after the crash, the state at disk will look identical in the INSERT, UPDATE and DELETE scenarios. Therefore, remove the tests.
-
由 Heikki Linnakangas 提交于
These tests set the appendonly_delete fault injection trigger, and then executed a TRUNCATE or ALTER TABLE DROP COLUMN on the table. However, neither command performs any DELETEs on the target table, and therefore don't even hit the fault. This is effectively the same as just testing TRUNCATE or ALTER TABLE DROP COLUMN on an AOCS table without any faults, and we have tests for that elsewhere already (e.g. src/test/regress/input/uao_dml/uao_dml.source and src/test/regress/sql/alter_table_aocs.sql).
-
由 Heikki Linnakangas 提交于
ANALYZE used to be implemented with fairly complicated aggregate queries, to count distinct number of values, and gather many other statistics. Once upon a time, there was a bug in the planner, that it tried to use a hash aggregate, even if the data type wasn't hashable. That case was triggered by the internal queries that ANALYZE runs. ANALYZE has since been rewritten, and no longer issues such queries, so this test case isn't very interesting in its old form anymore. But the underlying problem, that we mustn't use a hash aggregate on a datatype that isn't hashable, would still be good to test. So write a new more targeted test for that, that doesn't involve ANALYZE.
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
Subpartition names are SQL identifiers, so you cannot use a plain integer as name, unless you quote it. There isn't really anything special here, and never was. The original bug report was: > I was trying to add subpartitions named 2001, 2002, 2003, etc. but was not > allowed: > ... > However it was allowed when the name was changed from a number to a string It was closed as "No fix needed", as that is expected behavior. I'm not sure why we bothered to add test cases for this originally, but I think we can just drop them now.
-
由 Heikki Linnakangas 提交于
The old test case was no longer testing what it was supposed to. The ancient bug reported as MPP-3115 was related to renaming a partition, but the behavior has changed since then, to not allow two partitions to have the same name. I couldn't see any tests that RENAME PARTITION enforces uniqueness, except for the special case that the new name is the same as the old, so I added a test for that to partition1.sql. Other than that, I think we can simply remove this test case as obsolete.
-
由 Heikki Linnakangas 提交于
Much of it was present in partition1 test already.
-
由 Heikki Linnakangas 提交于
We have some VACUUM FULL commands in other tests already, but these tests seem more comprehensive than the other tests.
-
由 Haozhou Wang 提交于
We will first support external table query execution on master segment before we fully support task dispatch on master segment. 1. Modify grammar to enable ON clause for external table. 2. Modify ExtTableEntry catalog to record on clause. 3. Update legacy planner to support on clause for external table. 4. Update pg_dump. 5. Update regress tests. Signed-off-by: NHaozhou Wang <hawang@pivotal.io> Signed-off-by: NAdam Lee <ali@pivotal.io> Signed-off-by: NYuan Zhao <yuzhao@pivotal.io> * Update catalog version For "Support ON MASTER clause for external table" * Add on master regression tests for gpcloud
-
- 19 2月, 2017 4 次提交
-
-
由 Heikki Linnakangas 提交于
ORCA acquires different locks. Same problem that was fixed in the main test suite by commit b3e13f6b.
-
由 Heikki Linnakangas 提交于
ORCA acquires locks on tables with these operations. Just memorize the expected output.
-
由 Heikki Linnakangas 提交于
Change the queries that check tuple counts on a particular segment, in utility mode, to not print out the exact tuple counts, but a crude classification of 0, 1, <5 or more tuples. That's less sensitive to how the tuples are distributed across segments. The locks_reindex test is moved to the regular regression suite. I rewrote it to use a more advanced "locktest" view, copied from the partition_locking test, which doesn't rely on utility mode. These changes should make the tests work with even larger clusters, but I've only tested with 1, 2, and 3 nodes.
-
由 Heikki Linnakangas 提交于
This new "isolation2" suite uses the same Python helper that TINC used, to run these special isolation test cases.
-
- 18 2月, 2017 7 次提交
-
-
由 Heikki Linnakangas 提交于
These tests merely test that "gpinitactivestandby --help" and "gpinitstandby --help" produce a particular output. That's not very interesting, --help seems highly unlikely to suddenly stop working. Also, memorizing the exact help output in a test adds a hurdle to keeping the --help text up-to-date - you will need to remember to update the test too, whenever you update the help text. What would be useful, is a test to check that --help covers all the options and provides useful advice to a DBA. But that cannot be automated.
-
由 Heikki Linnakangas 提交于
I removed the last tests from that directory in commit 4d23ab19.
-
由 Shreedhar Hardikar 提交于
-
由 Heikki Linnakangas 提交于
These tests need the usual "lineitem", "orders" and "suppliers" test tables, but use only a subset of the data that we have in the the data/*.csv files. Therefore, split the csv files into two parts, the "small" set, used by these new tests, and the rest.
-
由 Heikki Linnakangas 提交于
-
由 Heikki Linnakangas 提交于
I tried reverting the commit that fixed the bug, but I couldn't actually reproduce the original bug anymore. But this is a very quick query, so might as well keep it.
-
由 Heikki Linnakangas 提交于
-
- 17 2月, 2017 6 次提交
-
-
由 Heikki Linnakangas 提交于
I had to change some of the tests that used 4 tests rows, to have more (9), to make them pass on a 3 segment cluster. If you only insert 4 rows to an external table, some segments might not receive any rows, and reading from the same file later will fail because the file wasn't created. I also changed the queries that tested that rows are distributed evenly, to work with a different number of segments. Hook up the new tests to installcheck-world.
-
由 Heikki Linnakangas 提交于
The explain plan with ORCA spells Seq Scan as Table Scan. Add alternative expected output for that.
-
由 Heikki Linnakangas 提交于
The main ExplainAnalyzeTestCase tests in here were running standard TPC-H-like test queries, and checking that the EXPLAIN ANALYZE output contains a "Memory: " line for every plan node. That seems a bit excessive, because looking at how those lines are printed, there is no reason to believe that you might have a Memory line for some nodes but not others. I don't think we need to test for that. In order to still have minimal coverage for the explain_memory_verbosity GUC, add a small test case to the main regression suite for that. The mpp20785 test was testing for an old bug where you got an out of memory error with this query. However, the test was broken, because the test schema was nowhere to be found, so it simply resulted in a "schema not found" error. Perhaps we could put it back if we could find the original schema somewhere, but it's useless as it is.
-
由 Bhuvnesh Chaudhary 提交于
When we create Left Anti Semi Join relations in case the left side is a dummy relation, it implies that the join relation is also a dummy relation. Signed-off-by: NOmer Arap <oarap@pivotal.io>
-
由 Venkatesh Raghavan 提交于
ANALYZE should only produce leaf partitions stats when gucs optimizer_analyze_midlevel_partition and optimizer_analyze_root_partition are set to off This fix makes the behaviour of ANALYZE consistent with the intent of the GUCs.
-
This commit also resolves #1646. Porting only the function `tuplesort_get_stats` in tuplesort.c from the Postgres commit https://github.com/postgres/postgres/blob/9bd27b7c9e998087f390774bd0f43916813a2847/src/backend/utils/sort/tuplesort.c Link to gpdb-dev discussion - https://groups.google.com/a/greenplum.org/forum/#!topic/gpdb-dev/V-zIshnNzyE
-