Signed-off-by: NBen Christel <bchristel@pivotal.io>

Commit ec3370b0 converged the optimizer and planner behavior in terms
of constraint enforcement. This commit un-ignores the previously
generated files. We were scratching our heads when the "constraints" and
"sreh" tests were failing on our workstations because of a stale
optimizer answer file.
Signed-off-by: NTom Meyer <tmeyer@pivotal.io>

Signed-off-by: NJim Doty <jdoty@pivotal.io>

This reverts commit da4007b2 which
decreased the memory a SPI function can use, so lots of tests
failed with "insufficient memory reserved for statement".

Previously, mpp_resource_group_centos7 use bin_gpdb_centos7 directly
which may cause the inconsistence of bin_gpdb_centos7 and gpdb_src.
This commit pass through bin_gpdb_centos7 from gate_mm_misc_start to
avoid this even though it's not used by mm_misc jobs.

When resource group is enabled, initialization of
SPIMemReserved should not depend on statement_mem.

Some functions are only used in `assert()`, put these functions in
`#ifdef USE_ASSERT_CHECKING` to prevent compilation warnings.

MyProc stores resSlot instead of resSlotId now, but some merged PRs
still expect resSlotId. Updated.

* separate the ops on slot, group and self;
* use slot instead of slotId when possible;
* add slotId in slot struct;
* validate slot ownership;
* provide helper funcs for many typical operations;
* move DDL callback functions to resgroup.c;
* do not leak memory in DDL callback funcs;
* prevent wasting fixed quota due to rounding;
* remove unnecessary atomic ops;
* report original error messages in try catch block;
* begin with lower case in LOG_RESGROUP_DEBUG();
* clean up some uses of write_log();
Signed-off-by: NGang Xiong <gxiong@pivotal.io>

Dump runtime info of resgroup to help debug. Using `select value from pg_resgroup_get_status_kv('dump');` to trigger this function.

This fixes a flaky tinc test in which we fail over to a standby master, but
do not test to confirm the database is ready before querying it.
Signed-off-by: NXin Zhang <xzhang@pivotal.io>

Signed-off-by: NTaylor Vesely <tvesely@pivotal.io>

By looking at the Concourse database, we were able to find 3 jobs in the
pr pipeline that have failed due to timing out.  We are doubling the
timeouts for those 3 jobs only.
Signed-off-by: NAlexandra Wang <lewang@pivotal.io>

In the below referenced commit, we added a new boolean
validate_reloptions to the QueryDispatchDesc. In UTILITY MODE, the
query descriptor does not have its QueryDispatchDesc initialized so
the segment would PANIC. To fix this, we default validate_reloptions
to true if the QueryDispatchDesc is not initialized as expected before
the change.

Reference:
https://github.com/greenplum-db/gpdb/commit/a3c07830258d62ae86ce9418b84ff0ca2e73e514

Authors: Jimmy Yih and Abhijit Subramanya

With the new gpdb version 6 bump, we need to make sure that the catalog
foreign key json file gets update. Otherwise, gpcheckcat will not work
at all.

This is a follow up commit to d413c0dd

The answer files are generated with `US/Pacific` timezone in mind.
However, the test didn't fixed the timezone to `US/Pacific`, hence it
will fail if the host is running in a different timezone.

This fix use the GUC `timezone` to set the timezone for the test always
at `US/Pacific`.

(cherry picked from commit 0f139183)

These were left over from the 5X branch. The gptransfer 4.3 to master
test is still needed since this will be supported.
Signed-off-by: NChris Hajas <chajas@pivotal.io>

Previously, the utility only checked for the destination system to be on
GPDB5. Instead, check that the destination system is not gpdb4.
Signed-off-by: NJamie McAtamney <jmcatamney@pivotal.io>

When the gp_default_storage_options GUC was set and a table was
rewritten with ALTER TABLE REORGANIZE, the temp table generated would
take the storage options of the GUC instead of from the original
table. We should not be looking at default storage options when doing
internal queries. To prevent this, we add a boolean variable called
validate_reloptions to the QueryDispatchDesc so that QE segments will
know whether or not to use the default storage options.

Authors: Jimmy Yih and Abhijit Subramanya

This adds ulimit and core dump support.
Signed-off-by: NAshwin Agrawal <aagrawal@pivotal.io>

Similar to https://github.com/greenplum-db/gpdb/pull/3610.
This test may produce inconsistent result based on the partition which
it pick to validate the constraint. We have other places where we test
the similar intentions, so removing this flaky test.

Also removed the numbering of tests as it becomes cumbersome to maintain
the numbering.

Since we're now in GPDB 6.x, 5.x gppkg version are no longer compatible
with our tests. Update the generated gppkg for master.

Follow up commit on d413c0dd

Aside from being a good thing that we should do sooner or later anyway,
this silences some current test failures that were caused by the error
message differences by commit ec3370b0.

The column `surfacearea` is defined as type real, which captures only
approximate values instead of the exact value. This can cause flakiness
of the test if the column is used in aggregate functions. Hence,
updating the schema to use numeric datatype.
Signed-off-by: NSambitesh Dash <sambitesh.dash@gmail.com>

Use the external work to properly access the terraform created VMs,
otherwise, we will hang.
Signed-off-by: NShoaib Lari <slari@pivotal.io>

Signed-off-by: NC.J. Jameson <cjameson@pivotal.io>

Changes per PR feedback.
Signed-off-by: NShoaib Lari <slari@pivotal.io>

Terraform deployed machines uses less memory compared to pulse, so the
query that uses a lot of memoery was getting killed by the kernel OOM
manager.
Signed-off-by: NMarbin Tan <mtan@pivotal.io>

Signed-off-by: NMarbin Tan <mtan@pivotal.io>

Migrating gpexpand test from using pulse to terraform. This uses a new
feature added in CCP "NUMBER_OF_NODES" which deploys a specific amount
of VMs for the cluster.

Add CUSTOM_ENV and PRE_TEST_SCRIPT properties in order to run tests
with specific expectations.

This test UPDATE violates two constraints, and it's arbitrary which one it
fails on first. That's problematic, because the error message depends on
which constraint happens to be checked first.

We have tests for testing each failure individually, so testing a case that
fails them both doesn't seem very interesting. We will never reach the
actualy failure of both at the same time, because we bail out on first
error. So to make the output stable, remove the offending UPDATE.

I recently moved this query from TINC. It produced stable output before
commit ec3370b0, because the old error message with ORCA listed both violated
constraints, but now the error only complaints about the one it happened to
check first. This happens to be working on the master pipeline currently, but
we got a failure from this on the 8.4 merge branch we're working on. I'm not
sure what changed there, perhaps a concurrent vacuum or some other timing
difference, but in any case the output is not very well-defined.

Previous commit missed one instance of this.

The order that these INSERTs would attempt to insert the rows was not
well-defined, so it would vary from one run to another, which partition's
check constraint it hit first. That changes the error message, causing
sporadic failures. To fix, change the query so that all the matching rows
that are then being inserted go to the same partition.

This allows removing many alternative expected output files for ORCA.

The flag was added to ORCA in v2.48.0, so bump our dependency to that
version.