With persistent tables removed there are no more consumers of this
API, so remove it.

The change in index.c is a behavioral change. The behavior on reindexing
shared catalogs now matches upstream again. The rest is just removal of
dead code.

This test file is currently unused altogether. That's another issue we
should do something about, but let's at least remove these clearly obsolete
queries from it.

These changes were made obsolete by the removal of all the cdbdump code
(commit 8922315e).

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.

After finding a match in semijoin mode, arrange to advance to
the next outer tuple not next inner tuple after returning the
current match. The node->mj_MatchedOuter is always false here,
there is no need to check it.

Author: Max Yang <myang@pivotal.io>

* Package PXF server for centos and sles

* Skip pxf tarball for pxf pipelines

* Split compile_gpdb into two separate tasks - one with PXF and one without

* Restore SLES yaml jobs/implement suggestions

* docs: gpbackup new options -include-table -exclude-table

-Add new options
-Update AdminGuide

PR for 5X_STABLE
Will be ported to MAIN

* docs: gpbackup - fix typos

contrib/bufferedtest depends on LZJB code which was removed long
before the open sourcing of Greenplum, and contrib/varblocktest
hasn't built in a long time due to the Makefile being wonky. Since
noone has missed these tools, remove them rather than keeping dead
code around.

Resetting all the environment variables makes it difficult to use an
alternate Python installation (e.g. virtualenv). Make a copy of the
current env instead, and add our PIPELINE_FILE to that.

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

see commit 2a3d7742

In the first cut of the walreplication work, I left out the part that
drops a segfile during AO compaction, because there was no
straightforward native PostgreSQL function to drop just a single segfile.
However, that leads to a massive disk space leak, as the space freed by
VACUUM on an AO table is not reclaimed, until the same segment number is
used again for further insertions, so we clearly must do something about
that.

Instead of dropping the segfile altogether, like we used to, truncate the
file to 0 bytes. Mostly because that's more expedient to do, as we have
the functions to do that and to WAL-log that, whereas code to fully remove
just a single segfile doesn't exist. But if you squint a bit, you could
even call that an optimization: it saves the overhead of recreating the
file again, if you load more data to it later.

Pointed out by Coverity.

As Coverity pointed out, 'pelem' has already been dereferenced in the
function, and hence it can never be NULL here. And indeed it should never
be NULL.

With 'prule', we explicitly checked for NULL earlier in the function.

PR for 5X_STABLE
Will be ported to MAIN

* docs: plcontainer logging and attribute updates.

-attribute names have changed for logging, and network
-the GUC log_min_messages controls the log level
-add note information about controlling container lifetime

PR for 5X_STABLE
Will be ported to MAIN

* docs: update for pl/container logging

* docs: plcontainer - udpates based on review comments.

* docs - plcontainer - review updates from dev. tracker stories

Add limitations
  -pl/container not supported when GPDB is run in Docker
  -multi-dimensional array not supported

Add ID max length 63 bytes
Clarify terminology
Update example output
Fix edits and typos

* docs: plcontainer - fix runtime-add example

* docs: pl/container does not support PL/R multi-dim. arrays

* docs: plcontainer - In Docker Images section, remove references to Pivotal.

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.

The IDENTIFICATION stanza in the source files is of questionable
usefulness, but unexpanded CVS keywords that never existed in the
codebase where the expansion happened are even less useful.
Replace with the filepath to make these headers consistent with
upstream.

A PL/JAVA NULL point reference has been reported by coverity scan.
The issue is located in guc.c for a pljava guc option
"pljava_classpath_insecure" and fixed in this commit.

tuple store which just advances current position by N instead of getting
tuple N times.

Author: Max Yang <myang@pivotal.io>

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.

Make sure all merge related FIXME markers are following the same
format so that we don't accidentally overlook any due to not
matching the grep pattern used.

This backports the below commit which moved from the source timezone
file to the newly introduced compact format.

  commit 097b24cea68ac167a82bb617eb1844c8be4eaf24
  Author: Tom Lane <tgl@sss.pgh.pa.us>
  Date:   Sat Nov 25 15:30:11 2017 -0500

    Replace raw timezone source data with IANA's new compact format.

    Traditionally IANA has distributed their timezone data in pure source
    form, replete with extensive historical comments.  As of release 2017c,
    they've added a compact single-file format that omits comments and
    abbreviates command keywords.  This form is way shorter than the pure
    source, even before considering its allegedly better compressibility.
    Hence, let's distribute the data in that form rather than pure source.

    I'm pushing this now, rather than at the next timezone database update,
    so that it's easy to confirm that this data file produces compiled zic
    output that's identical to what we were getting before.

    Discussion: https://postgr.es/m/1915.1511210334@sss.pgh.pa.us