gp_resource_manager is reserved for later use to switch resource control stratagy from resource queue to an under-developing resource statagy named resource group. Eg:

gpconfig -c gp_resource_manager -v 'group'
gpconfig -c  gp_resource_manager -v 'queue'

To make it work, a restart of cluster is needed.

Current implementation of resource queue can not guaranty the strong
consistency of configuration of resource limit between catalog and
shared memory, so AssertMemoryLimitsMatch() is incorrect and
unreasonable. We may need to guaranty the consistency some day, but for
now just remove the obvious wrong assertion.

[ci skip]

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.

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.

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.

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

In PostgreSQL, the unlink is deferred and handled by checkpoint.

In GPDB, the unlink is always handled by persistent tables and hence it's
protected of duplicated relfilenode deletion during recovery. Functionally,
there is no harm to send unlink to checkpoint process, and checkpoint process
cannot even find the relfilenode to be deleted. However, this will be a
performance impact under scenario like deleting a table with large number of
partitions, where the fsync request queue is unnecessarily filled.

The detailed discussions are at:
https://groups.google.com/a/greenplum.org/forum/#!searchin/gpdb-dev/mdunlink%7Csort:relevance/gpdb-dev/PHKuQPNwWs0/1kIwDk-CEgAJ

We have good coverage of this in the 'analyze' test in the main test suite
now.

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.

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.

There's a test in the main suite's 'partition' test for this already,
with the 'deep_part' test table.

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.

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.

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.

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.

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.

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.

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.

________________________________________________________________________________________________________
*** CID 163038:  Uninitialized members  (UNINIT_CTOR)
/extensions/gpcloud/src/s3interface.cpp: 556 in S3MessageParser::S3MessageParser(const Response &)()
550     S3MessageParser::S3MessageParser(const Response &resp) {
551         // Compatible S3 services don't always return XML
552         if (resp.getRawData().data() == NULL) {
553             message = "Unknown error";
554             code = "Unknown error code";
555
>>>     CID 163038:  Uninitialized members  (UNINIT_CTOR)
>>>     Non-static class member "xmlptr" is not initialized in this constructor nor in any functions that it calls.
556             return;
557         }

________________________________________________________________________________________________________
*** CID 163037:  Uninitialized members  (UNINIT_CTOR)
/extensions/gpcloud/include/restful_service.h: 37 in Response::Response(ResponseStatus, PGAllocator<unsigned char> &)()
31     class Response {
32        public:
33         explicit Response(ResponseStatus status) : status(status) {
34         }
35         explicit Response(ResponseStatus status, S3MemoryContext& context)
36             : status(status), dataBuffer(context) {
>>>     CID 163037:  Uninitialized members  (UNINIT_CTOR)
>>>     Non-static class member "responseCode" is not initialized in this constructor nor in any functions that it calls.
37         }

________________________________________________________________________________________________________
*** CID 163033:  Uninitialized members  (UNINIT_CTOR)
/extensions/gpcloud/include/s3params.h: 13 in S3Params::S3Params(const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>> &, bool, const std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>> &, const
+std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>> &)()
7
8     class S3Params {
9        public:
10         S3Params(const string& sourceUrl = "", bool useHttps = true, const string& version = "",
11                  const string& region = "")
12             : s3Url(sourceUrl, useHttps, version, region), keySize(0), chunkSize(0), numOfChunks(0) {
>>>     CID 163033:  Uninitialized members  (UNINIT_CTOR)
>>>     Non-static class member "verifyCert" is not initialized in this constructor nor in any functions that it calls.
13         }

________________________________________________________________________________________________________
*** CID 163032:  Error handling issues  (UNCAUGHT_EXCEPT)
/extensions/gpcloud/src/compress_writer.cpp: 9 in CompressWriter::~CompressWriter()()
3     uint64_t S3_ZIP_COMPRESS_CHUNKSIZE = S3_ZIP_DEFAULT_CHUNKSIZE;
4
5     CompressWriter::CompressWriter() : writer(NULL), isClosed(true) {
6         this->out = new char[S3_ZIP_COMPRESS_CHUNKSIZE];
7     }
8
>>>     CID 163032:  Error handling issues  (UNCAUGHT_EXCEPT)
>>>     An exception of type "S3RuntimeError" is thrown but the throw list "throw()" doesn't allow it to be thrown. This will cause a call to unexpected() which usually calls terminate().
9     CompressWriter::~CompressWriter() {
10         this->close();
11         delete this->out;
12     }

________________________________________________________________________________________________________
*** CID 163029:  Memory - illegal accesses  (STRING_NULL)
/extensions/gpcloud/src/gpwriter.cpp: 49 in _ZN8GPWriter18constructRandomStrB5cxx11Ev()
43     string GPWriter::constructRandomStr() {
44         int randomDevice = ::open("/dev/urandom", O_RDONLY);
45         char randomData[32];
46         size_t randomDataLen = 0;
47
48         while (randomDataLen < sizeof(randomData)) {
>>>     CID 163029:  Memory - illegal accesses  (STRING_NULL)
>>>     Function "read" does not terminate string "randomData[randomDataLen]".

________________________________________________________________________________________________________
*** CID 163028:  Performance inefficiencies  (PASS_BY_VALUE)
/extensions/gpcloud/src/s3interface.cpp: 265 in S3InterfaceService::listBucket(S3Url)()
259     // ListBucket lists all keys in given bucket with given prefix.
260     //
261     // Return NULL when there is failure due to network instability or
262     // service unstable, so that caller could retry.
263     //
264     // Caller should delete returned object.
>>>     CID 163028:  Performance inefficiencies  (PASS_BY_VALUE)
>>>     Passing parameter s3Url of type "S3Url" (size 256 bytes) by value.
Signed-off-by: NHaozhou Wang <hawang@pivotal.io>
Signed-off-by: NYuan Zhao <yuzhao@pivotal.io>
Signed-off-by: NAdam Lee <ali@pivotal.io>

Without this commit, test scripts will re-compile gpcloud anyway, better
to use the one from package instead in the main pipeline.

[ci skip]

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.

If the segrelid, visimaprelid, or the visimapidxid fields are 0 for an AO
table, then error out.

These are already covered by the 'appendonly' and 'uao_dml/uao_dml' tests
in the main test suite.

"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.

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.

PR pipeline: use 'max_in_flight: 1' and 'version: every' to ensure all PRs flow through the pipeline
Signed-off-by: NJingyi Mei <jmei@pivotal.io>

Signed-off-by: NTom Meyer <tmeyer@pivotal.io>

Signed-off-by: NTom Meyer <tmeyer@pivotal.io>