Fixes for:
- PGAC_FUNC_GETTIMOFDAY_1ARG and
- PGAC_FUNC_GETPWUID_R_5ARG

Update the C code for ACX_PTHREAD from the autoconf-archive

The relevant changes come from these commits:
- http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=commitdiff;h=0728dab771b2a4da8032d5f0ade8870add680b39
- http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=commitdiff;h=7a6c511965489c38f5d3bef4afe113e3fe11c2ac

> This can be used to mark custom built binaries with an extra version
> string such as a git describe identifier or distribution package release
> version.

From: Oskari Saarenmaa <os@ohmu.fi>
Originally commited by Peter Eisentraut, adapted by Pivotal.
(cherry picked from commit 46328916)

We already had the pointer size check in the upstream order in our
genesis open source commit 6b0e52be , but we seem to have missed the
rest of the rearrangement from upstream.

This commit completes that cherry-pick, to reduce merge diff with
(admittedly much later) commit 46328916 .

> Doesn't seem like a good idea to be doing AC_CHECK_SIZEOF(void *) so much
> earlier than all the other sizeof checks, and it certainly fails to follow
> the order suggested at the file head.  Rearrange.
Author: Tom Lane
Adapted by Pivotal

(cherry picked from commit 075ac80d)

(cherry picked from commit b32a290b)

The concept of optimization levels is known in many enterprise
optimizers. It enables user to handle the degree of optimization that is
being employed. The optimization levels allow the grouping of
transformations into bags of rules (where each is assigned a particular
level). By default all rules are applied, but if a user wants to apply
fewer rules they are able to. This decision is made by them based on
domain knowledge, and they know even with fewer rules being applied the
plan generated satisfies their needs.

The Cascade optimizer, on which GPORCA is based on, allows grouping of
transformation rules into optimization levels. This concept of
optimization levels has also been extended to join ordering allowing
user to pick the join order via the query or, use greedy approach or use
exhaustive approach.

Postgres based planners use join_limit and from_limit to reduce the
search space. While the objective of Optimization/Join is also to reduce
search space, but the way it does it is different. It is requesting the
optimizer to apply or not apply a subset of rules and providing more
flexibility to the customer. This is one of the most frequently
requested feature from our enterprise clients who have high degree of
domain knowledge.

This PR introduces this concept. In the immediate future we are planning
to add different polynomial join ordering techniques with guaranteed
bound as part of the "Greedy" search.
Signed-off-by: NHaisheng Yuan <hyuan@pivotal.io>

Fix it for realz. :(

Building with PXF was made the default in df1d6ccb,
but the autoconf --help message was missed. Update to match the
default config.

    commit 55fb759a
    Author: Peter Eisentraut <peter_e@gmx.net>
    Date:   Tue Jun 3 22:36:35 2014 -0400

        Silence Bison deprecation warnings

        Bison >=3.0 issues warnings about

            %name-prefix="base_yy"

        instead of the now preferred

            %name-prefix "base_yy"

        but the latter doesn't work with Bison 2.3 or less.  So for now we
        silence the deprecation warnings.

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.

* Enable PXF by default for GPDB builds

* Disable pxf wherever libcurl is disabled

Leverage the core autoconf scaffolding for resolving the dependency
on libcurl. Enabling PXF in autoconf now automatically adds libcurl
as a dependency. Coupled with the recent commit which relaxes the
curl version requirement on macOS, we can remove the library copying
from the PXF makefile as well.

GPOS raises exception with different severity level, but
they were being logged to GPDB logs at LOG severity level.
This disabled users to not turn off logging for GPOS exceptions, unless
GPDB log setting was changed higher than LOG severity level.

This is the initial commit which introduces the functionality. If an
exception is created without the GPDB severity level, it will default to
LOG severity level in GPDB.
Signed-off-by: NJemish Patel <jpatel@pivotal.io>

The pipeline was failing as the ORCA tag for 2.45.0 was not pushed.
It is currently available.

This reverts commit 378426fe.

> --2017-09-17 12:12:00--  https://github.com/greenplum-db/gporca/releases/download/v2.45.0/bin_orca_centos5_release.tar.gz
> Resolving github.com... 192.30.255.113, 192.30.255.112
> Connecting to github.com|192.30.255.113|:443... connected.
> HTTP request sent, awaiting response... 404 Not Found
> 2017-09-17 12:12:00 ERROR 404: Not Found.

While attempting to decorrelate the subquery, we were
incorrectly pulling up the join before calculating the window function
of the results of the join. In cases where we have subqueries with
window function and the subquery has outer references we should not
attempt decorrelating it.

There are further optimization which can be done in case of existential
queries but this PR fixes the plan.
Signed-off-by: NJemish Patel <jpatel@pivotal.io>

The bzip2 library is only used by the gfile/fstream code, used for external
tables and gpfdist. The usage of bzip2 was in #ifndef WIN32 blocks, so it
was only built on non-Windows systems.

Instead of tying it to the platform, use a proper autoconf check and
HAVE_LIBBZ2 flags. This makes it possible to build gpfdist with bzip2
support on Windows, as well as building without bzip2 on non-Windows
systems. That makes it easier to test the otherwise Windows-only codepaths
on other platforms. --with-libbz2 is still the default, but you can now use
--without-libbz2 if you wish.

I'm sure that some regression tests will fail if you actually build the
server without libbz2, but I'm not going to address that right now. We have
similar problems with other features that are in principle optional, but
cause some regression tests to fail.

Also use "#ifdef HAVE_LIBZ" rather than "#ifndef WIN32" to enable/disable
zlib support in gpfdist. Building the server still fails if you use
--without-zlib, but at least you can build the client programs without
zlib, also on non-Windows systems.

Remove obsolete copy of bzlib.h from the repository while we're at it.

* Use built-in JSON parser for PXF fragments

Instead of relying on a external library, use the built-in JSON
parser in the backend for the PXF fragments parsing. Since this
replaces the current implementation with an event-based callback
parser, the code is more complicated, but dogfooding the parser
that we want extension writers to use is a good thing.

This removes the dependency on json-c from autoconf, and enables
building PXF on Travis for extra coverage.

* Use elog for internal errors, and ereport for user errors

Internal errors where we are interested in source filename should
use elog() which will decorate the error messages automatically
with this information. The connection error is interesting for the
user however, use ereport() instead there.

The perl code in src/test/regress was using a mix of either not
printing the version, printing it wrong (due to us not using CVS
anymore) or using a hardcoded string. Implement a new module for
common test code called GPTest.pm which abstracts this (for now
it's the only thing it does but this might/will change, hence the
name). The module is created by autoconf to make it pull in the
GP_VERSION from there.

While there, simplify the version output in gpdiff which included
the version of the system diff command - somewhat uninteresting
information as it's not something that changes very often and just
cluttered up the output.

This removes the MakeMaker support but since we have no intention
of packaging these programs into a CPAN module it seems pointless
to carry that format around.

Signed-off-by: NOmer Arap <oarap@pivotal.io>
Signed-off-by: NDhanashree Kashid <dkashid@pivotal.io>

* Refactor GPHDFS regression to run for pxf

* remove customized Hadoop home location

* PXF tarball creation inside GPDB pipeline

* Remove legacy directory

* Use enable_pxf instead of with_pxf

Per discussion at https://github.com/greenplum-db/gpdb/pull/2379, we don't
really need to use a special, patched, version of Xerces-C. Remove the
check.

Signed-off-by: NLav Jain <ljain@pivotal.io>
Signed-off-by: NOleksandr Diachenko <odiachenko@pivotal.io>
Signed-off-by: NShivram Mani <smani@pivotal.io>
Signed-off-by: NJohn Gaskin <jgaskin@pivotal.io>
Signed-off-by: NAlexandra Wang <lewang@pivotal.io>

Record the version in configure.in for releases which are not full
Git trees.

Fix Relcache Translator to send CoercePath info

Currently ORCA crashes while executing following query:
```
CREATE TABLE FOO(a integer NOT NULL, b double precision[]);
SELECT b FROM foo
UNION ALL
SELECT ARRAY[90, 90] as Cont_features;
```

In the query, we are appending an integer array (ARRAY[90, 90]) to a double
precision array (foo.b) and hence we need to apply a cast on ARRAY[90, 90] to
generate ARRAY[90, 90]::double precision[].
In gpdb5 there is not direct function available that can cast array of any type
to array of any other type.
So in relcache to dxl translator we look into the array elements and get their type
and try to find a cast function for them.  For this query, source type is 23 i.e.
integer and destination type is 701 i.e. double precision and we try to find if
we have a conversion function for 23 -> 701. Since that is available we send
that function to ORCA as follows:
```
<dxl:MDCast Mdid="3.1007.1.0;1022.1.0"
Name="float8" BinaryCoercible="false" SourceTypeId="0.1007.1.0"
DestinationTypeId="0.1022.1.0" CastFuncId="0.316.1.0"/>
```
Here we are misinforming ORCA by specifying that function with id 316 is available
to convert type 1007 i.e. integer array to 1022 i.e. double precision array.
However Function id 316 is simple int4 to float8 conversion function and it CAN NOT
convert an array of int4 to array of double precision. ORCA generates a plan
using this function but executor crashes while executing this function because
this function can not handle arrays.

This commit fixes this issue by passing a ArrayCoercePath info to ORCA.
In Relcache Translator, The appropriate cast function is retrieved in `gpdb::FCastFunc()`
which relies on `find_coercion_pathway()` to provide the cast function oid given the src
and dest types.

`find_coercion_pathway()` does not just determines the cast function to be used but
also determines the coercion path; however we ignored the coercision path
and generate a simple Cast Metadata Object.

With this commit, we now pass the pathtype to relcache translator and
generate ArrayCoerceCast Metadata object depending on the coercion path.

In ORCA, when the dxl is translated to expression, we check the path type along with
the cast function and generate `CScalarArrayCoerceExpr` if the path type is
array coerce path; otherwise we generate simple `CScalaraCast`.

Please check the corresponding ORCA PR.

Bump ORCA version to 2.40
Signed-off-by: NBhuvnesh Chaudhary <bchaudhary@pivotal.io>

Ants Aasma and Jeff Davis

(cherry picked from commit fdea2530)

Signed-off-by: NShoaib Lari <slari@pivotal.io>

* Port Postgres TAP SSL tests
Signed-off-by: NYuan Zhao <yuzhao@pivotal.io>

* Add config to enable tap tests
Signed-off-by: NYuan Zhao <yuzhao@pivotal.io>

1. Add enable-tap-tests flag to control tests.
2. Add Perl checking module.
3. Enable tap tests for enterprise build by default.

* Adapt postgres tap tests to gpdb

1. Assume a running GPDB cluster instance(gpdemo), instead of
using temp installation. Remove most node init operation.
Disable environment variable override during test init.

2. Replace node control operation with GPDB counterpart:
start   -> gpstart -a
stop    -> gpstop -a
restart -> gpstop -arf
reload  -> gpstop -u

disable promote, add restart_qd.
restart_qd -> pg_ctl -w -t 3 -D $MASTER_DATA_DIRECTORY

3. Add default server key and certificate for GPDB.

4. Update server setup to work with running gpdemo.

5. Disable SSL alternative names cases.
Signed-off-by: NYuan Zhao <yuzhao@pivotal.io>

Signed-off-by: NDhanashree Kashid <dkashid@pivotal.io>

Signed-off-by: NEkta Khanna <ekhanna@pivotal.io>

* Remove PartOidExpr, it's not used in GPDB.

The target lists of DML nodes that ORCA generates includes a column for the
target partition OID. It can then be referenced by PartOidExprs. ORCA uses
these to allow sorting the tuples by partition, before inserting them to the
underlying table. That feature is used by HAWQ, where grouping tuples that
go to the same output partition is cheaper.

Since commit adfad608, which removed the gp_parquet_insert_sort GUC, we
don't do that in GPDB, however. GPDB can hold multiple result relations open
at the same time, so there is no performance benefit to grouping the tuples
first (or at least not enough benefit to counterbalance the cost of a sort).

So remove the now unused support for PartOidExpr in the executor.

* Bump ORCA version to 2.37
Signed-off-by: NEkta Khanna <ekhanna@pivotal.io>

* Removed acceptedLeaf
Signed-off-by: NEkta Khanna <ekhanna@pivotal.io>