A long time ago, they were disabled, because the GIN code had not been
modified to work with file replication. Now with WAL replication, there's
no reason to not support them.

They were not testing anything interesting anymore. Per discussion on
gpdb-dev mailing list.

Discussion: https://groups.google.com/a/greenplum.org/d/msg/gpdb-dev/gq07ixYkTqk/ehLfByeIAAAJ

This test keeps failing in CI intermittently, needs to be looked into as seems
hitting the assertion currently
"Unexpected internal error (postmaster.c:5328)","FailedAssertion(""!(CountChildren(0x0001|0x0002) == 0)"", File: ""postmaster.c"", Line: 5328)"

Once postmaster cleanup PR is done will revisit the test.

Since ICW is a very longrunning process, attempt to reduce time
consumption by reducing overhead during testing while keeping the
test constant (coverage not reduced).

Avoid dropping/recreating underlying test tables when not required,
reduce the number of partitions in some cases and skip pointless
drops for objects we know doesn't exist. In total this shaves about
30-40 seconds off an ICW run on my local machine, mileage may vary.

Make sure that we are able to exchnage in an external partition, and
also ensure that truncation doesn't recurse into the ext partition.

The timezone data in Greenplum are from the base version of
PostgreSQL that the current version of Greenplum is based on.
This cause issues since it means we are years behind on tz
changes that have happened. This pulls in the timezone data
and code from PostgreSQL 10.1 with as few changes to Greenplum
as possible to minimize merge conflicts. The goal is to gain
data rather than features, and for Greenplum for each release
to be able to stay current with the iana tz database as it is
imported into upstream PostgreSQL.

This removes a Greenplum specific test for the Yakutsk timezone
as it was made obsolete by upstream tz commit 1ac038c2c3f25f72.

pg_ctl and gpstart appear to be running simultaneously, because we're
not waiting for pg_ctl to finish before moving to the next call.
(subprocess.Popen() doesn't return the process's return code -- it
returns a Popen instance.)

cs_walrep_2 in the master pipeline is currently failing roughly 50% of
the time due to a crash during test_negative. Let's see if this helps at
all.

Author: Xin Zhang <xzhang@pivotal.io>
Author: Jimmy Yih <jyih@pivotal.io>
Author: Ashwin Agrawal <aagrawal@pivotal.io>

dbid is not consistent (like content 0 mirror will always have dbid 5), as
segments get created in parallel and get assigned those based on order of
execution. Hence better convention to use is content-id, to specify which
segment to connect. Framework currently connects to primary of specified
content-id.

If later needed, maybe when we enable hot-standby feature can extend further to
start supporting connecting to specified content-ids mirror as well. Not
something needed as of now.

Author: Xin Zhang <xzhang@pivotal.io>
Author: Ashwin Agrawal <aagrawal@pivotal.io>

The test uses \retcode to ignore the output of the external script, but
remember the return code in the expected result.

It's very useful for this scenario to ensure, we don't care for the
details of the recoveryfull operation, but we do care this operation
complete successfully.

The test stop the primary and trigger failover to its mirror, then fail
back to the original segment configuration. At the end of the test, the
gp_segment_configuration is the same as the beginning of the test.

Author: Xin Zhang <xzhang@pivotal.io>
Author: Jacob Champion <pchampion@pivotal.io>
Author: Ashwin Agrawal <aagrawal@pivotal.io>

Author: Xin Zhang <xzhang@pivotal.io>
Author: Ashwin Agrawal <aagrawal@pivotal.io>

In the past, the utility mode will not be retried, and caused wrong
behavior when trying to connect to given segment under utility mode.

In this refactoring, both utility mode and normal mode will go through
connectdb() that has the retry logic.

Author: Xin Zhang <xzhang@pivotal.io>
Author: Ashwin Agrawal <aagrawal@pivotal.io>

We don't want to diff the output from `segwalrep.py recoverfull`, but we
do want to know if the command has succeeded or not. Add a new execution
mode, invoked via

    !\retcode EXECUTABLE [OPTIONS ...]

which will bracket the program's stdout/stderr with begin/end_ignore,
and also print out an exit code (which is not ignored).

Author: Jacob Champion <pchampion@pivotal.io>
Author: Xin Zhang <xzhang@pivotal.io>
Author: Ashwin Agrawal <aagrawal@pivotal.io>

There is no reason to believe that these bugs could reappear, in the same
form.

There is a race condition in this test, where our disabling of the FTS
probe process doesn't actually have to happen immediately (it takes a
little while for the GUC to propagate). This may be the cause of some
test failures we see where the primary is falling out of sync with the
mirror before we want it to.

Try a basic hack to see if it helps anything; the real fix will be to
move to faultinjection, but that's another story.

Author: Ashwin Agrawal <aagrawal@pivotal.io>
Author: Jacob Champion <pchampion@pivotal.io>

synchronous_standby_names is set on the first FTS probe after starting
the cluster, and it's written to disk, but it doesn't actually get
persisted in memory on all cluster processes. The backend that "sets"
the value exits without SIGHUP'ing the cluster, and it therefore
"resets" to the empty string. If you're lucky enough to restart the
cluster after this point, everything works as expected, but until then
the cluster is in a strange state.

This test (which currently fails) verifies that the
synchronous_standby_names GUC is actually set appropriately on the
segment.

The column is called 'datadir', not 'directory'.

Author: Xin Zhang <xzhang@pivotal.io>
Author: Ashwin Agrawal <aagrawal@pivotal.io>

We will not be supporting these utilities in GPDB 6.

References to gpcrondump and gpdbrestore in the gpdb-doc directory have been left
intact, as the documentation will be updated to refer to gpbackup and gprestore
in a separate commit.

Author: Jamie McAtamney <jmcatamney@pivotal.io>

Once this gos through in CI, will help to reduce one more job and there by
elimintae one more VM expense.

* Fix tests associated filespace.
* Update expected result of gpinitstandby with no standby_master directory.

Author: Max Yang <myang@pivotal.io>
Author: Xiaoran Wang <xiwang@pivotal.io>

gpcheckmirrorseg needs to be reimplemented, if we want to keep doing this
kind of calidation.

* Change test cases for gpinistandby -F parameter.
* Fix get standby data directory by gp_segment_configuration instead of pg_filespace_entry
* Fix gpinitstandby to follow old behavior if option -d not given

Author: Xiaoran Wang <xiwang@pivotal.io>
Author: Max Yang <myang@pivotal.io>

Author: Xin Zhang <xzhang@pivotal.io>
Author: Ashwin Agrawal <aagrawal@pivotal.io>

The failure was due to filespace removal. Fixed to use correct syntax.

Author: Xin Zhang <xzhang@pivotal.io>
Author: Ashwin Agrawal <aagrawal@pivotal.io>

If this works will remove all other pg_twophase make targets and jobs
from CI. As to run one test creating the full VM, is not efficient.

Filespaces are no more.