pg_amop, pg_amproc oids are not synchronized from master and segments, hence
adding them to known differences. There are more tables which needs to be
cleaned-up here based on function RelationNeedsSynchronizedOIDs() in catalog.c
based leaving that for separate commit.

Also, since there exist simpler way to skip performing check for column use the
same for `indcheckxmin` column of pg_index instead of what was added as part of
commit 79caf1c0

Also, cleanup some checks existing for versions prior to 4.1.

Currently, SPLIT partition of multi-level partition tables's default partition
causes catalog inconsistency as constraint is not created for newly created
tables. Hence, to enable running gpcheckcat from running after ICW drop the
table as temp fix.

gpcheckcat would be handy to detect any catalog issues introduced, hence start
running the same at end of ICW. Also, make sure different targets do not use
regression database but database of their own.

-- for guc's that are read-only when not accompanied by
--skipvalidation,
-- instead of saying a hidden guc doesn't exist, say that it is not
changeable and refer user to documentation
Signed-off-by: NChumki Roy <croy@pivotal.io>

- BLD_PYTHON -> PYTHONHOME.
- New variable PYTHON is the python binary.
- Export both PYTHON and PYTHONHOME.
- Remove unused BLD_PYTHON_PERFMON variables.
Signed-off-by: NDavid Sharp <dsharp@pivotal.io>

Signed-off-by: NNing Yu <nyu@pivotal.io>

Any resgroups created by CREATE RESOURCE GROUP syntax can be dropped
with DROP RESOURCE GROUP syntax; the default resgroups, default_group
and admin_group, can't be dropped; only superuser can drop resgroups;
resgroups with roles bound to can't be dropped.

    -- drop a resource group
    DROP RESOURCE GROUP rg1;

*NOTE*: this commit only implement the DROP RESOURCE GROUP syntax, the
actual resource management are not yet supported, which will be provided
later based on these syntax commits.

*NOTE*: test cases are provided for both CREATE and DROP syntax.
Signed-off-by: NPengzhou Tang <ptang@pivotal.io>

There are two default resource groups 'default_group' and 'admin_group',
to create more please use the CREATE RESOURCE GROUP command, group
options can be specified with the WITH clause, at the moment
'cpu_rate_limit' and 'memory_limit' are mandatory, other options are
all optional.

    -- create a resource group
    CREATE RESOURCE GROUP rg1 WITH (
        concurrency=1,
        cpu_rate_limit=.2,
        memory_limit=.2
    );
    -- query the resource group
    SELECT oid FROM pg_resgroup WHERE rsgname='rg1';
    SELECT * from gp_toolkit.gp_resgroup_config
        WHERE groupname='rg1';
    -- create/alter a role and assign it to this group
    CREATE ROLE r1 RESOURCE GROUP rg1;
    ALTER ROLE r2 RESOURCE GROUP rg1;

*NOTE*: this commit only implement the SQL syntax, the actual resource
limitation will not take effect at the moment as the resource group is
still under development.

*NOTE*: test cases are not included in this commit as once a testing
resgroup is created it can't be dropped due to lack of DROP syntax, so
the test case can't be re-run and will introduce side-effect to the
system. So it's better to provide test cases after the DROP RESOURCE
GROUP is implemented.
Signed-off-by: NNing Yu <nyu@pivotal.io>

gpfdist waits 5 seconds to close SSL sessions to workaround a system
related issue on Solaris, this commit restricts the workaround to
cmdline only.
Signed-off-by: NAdam Lee <ali@pivotal.io>
Signed-off-by: NYuan Zhao <yuzhao@pivotal.io>

- If you are working on a computer and want to get the entirety of the
  source code of gpdb including submodules, you cannot do that as you would need your github
  key to clone the submodules.

fix tests, add init_file to ignore GPDB segment output
use init_file from main regression tests, fix expected results
Requires GPDB to be configure with --with-openssl to pass

qp_olap_group2 did an elaborate dance with optimizer_log=on,
client_min_messages=on, and gpdiff rules to detect whether the queries
fell back to the traditional planner. Replace all that with the new simple
optimizer_trace_fallback GUC.

Also enable optimizer_trace_fallback in the 'gp_optimizer' test. Since this
test is all about testing ORCA, seems appropriate to memorize which queries
currently fall back and which do not, so that we detect regressions where
we start to fall back on queries that ORCA used to be able to plan. There
was one existing test that explicitly set client_min_messages=on, like the
tests in qp_olap_group2, to detect fallback. I kept the those extra logging
GUCs for that one case, so that we have some coverage for that too, although
I'm not sure how worthwhile it is anymore.

In the passing, in the one remaining test in gp_optimizer that sets
client_min_messages='log', don't assume that log_statement is set to 'all'.

Setting optimizer_trace_fallback=on for 'gp_optimizer' caught the issue
I fixed in previous commit, that one of the ANALYZE queries still used ORCA.

For the same reasons we disabled ORCA in all the other ANALYZE queries.
Missed this one.

I belive we don't want to use ORCA for any of the ANALYZE's internal
queries, current or future ones, so move the disabling of ORCA one level
up, into a wrapper around analyze_rel().

[ci skip]

* docs: fix broken links and permanent redirects

* fix doubled slashes in URLs

add_second_stage_agg() builds a SubQueryScan, and moves the "current" plan
underneath it. The SS_finalize_plan() call was misplaced, it needs to be
called before constructing the new upper-level range table, because any
references to the range table in the subplan refer to the original range
table, not the new dummy one that only contains an entry for the
SubQueryScan. It looks like the only thing in SS_finalize_plan() processing
that accesses the range table is processing a TableFunctionScan. That lead
to an assertion failure or crash, if a table function was used in a query
with an aggregate.

Fixes github issue #2033.

* added tests from upstream for oracle_compat

backport of upstream commit 607b2be7, from PostgreSQL 8.4? 

This removes uninteresting tests, and tests covering functionality
which is tested elsewhere. The superflous search_path setting is
removed, the amount of tables created reduced and the test data size
reduced. The resource_queue test was more or less duplicated already
but had enough interesting bits to warrant a move to the appropriate
suite.

This shaves roughly 20% of the runtime of tbe test suite.

Commit f004451e forgot to use @abs_srcdir@ in the expected output.

And remove the rest of old partition_exchange TINC test. We already had
tests in 'partition' test file, for validating that the values in the
exchanged table are valid for the partition (search for "-- validation").

There were also tests for exchanging a partition in a hash partitioned
table, but the validation hasn't apparently been implemented for hash
partitions, and they're not supported anyway, so that doesn't seem very
interesting to test.

The old cdbfast test suite had this, move to ICW.
Signed-off-by: NAdam Lee <ali@pivotal.io>
Signed-off-by: NYuan Zhao <yuzhao@pivotal.io>

The old cdbfast test suite had tests for these, looks good, move to ICW.
Signed-off-by: NAdam Lee <ali@pivotal.io>
Signed-off-by: NYuan Zhao <yuzhao@pivotal.io>

* GPDB DOCS Configuring clients w/ Kerberos or Active Directory

* GPDB DOCS updates to support client kerb/AD topics

[ci skip]

This commit brings the ps_status.c file closer to upstream and reverts all the
changes made to support gpkill utiltity which is obsolete now. Full removal of
GPKILL utility code will done as part of separate commit.

Seems 8.3 merge messed up the ps display logic, ends up missing to print useful
information for process like what command its running, waiting for lock,
etc. Also introduces newline causing the output tonot look tidy. It seem was
broken much more for MAC than other platforms, this commit fixes to correctly
report the useful process information.

I'm not sure if it's really worthwhile to test all of these with and
without CTE inlining, but kept it for now.

Clean up tuplesort code for 8.4 merge
  * Move private tuplesort_mk.h to tuplesort__mk_details.h
  * Move mksort API to tuplesort_mk.h
  * Move GPDB introduced tuplesort API to tuplesort_gp.h
  * Reorganize tuplesort.c to move all GPDB related functions to the end.
Signed-off-by: NKarthikeyan Jambu Rajaraman <karthi.jrk@gmail.com>

`-[ "$str" = "foo" ] && $(MAKE) -C bar` ignores errors while making bar,
better to use full `if-then` clause.

I modified the test slightly, to eliminate the sleep, making the test run
faster.

We have a test for this in the main test suite, in the 'partition' test.
This one:

create table rank_damage (i int, j int)  partition by range(j) (start(1)
end(10) every(1));
-- [other tests]
alter table rank_damage_1_prt_1 drop constraint rank_damage_1_prt_1_check;

> src/bin/gpfdist/ext is a submodule, from
> https://github.com/greenplum-db/gpfdist-ext. It contains tarballs of libapr,
> libevent, openssl and zlib, and a bunch of patches. Why do we build gpfdist
> like that? On my laptop, I never use those ancient, patched, versions, I
> link with the normal libraries that come with my distribution, and it works
> fine.
>
> I think that has something to do with Windows, because I also found this in
> src/interfaces/libpq/Makefile:
>
> ifeq ($(PORTNAME), win32)
> SHLIB_LINK += -L../../../../gpAux/ext/win32/kfw-3-2-2/lib
> -L../../../src/bin/gpfdist/ext/lib -lgssapi32 -lshfolder -lwsock32 -lws2_32
> -lsecur32 $(filter -leay32 -lssleay32 -lcomerr32 -lkrb5_32, $(LIBS))
> endif
>
> But if that's only for Windows builds, why do we try to build it on Linux?
>
> - Heikki

Thanks Heikki for bringing this up, we created a story to review the
gpfdist/ext submodule, this commit is to remove it from other OSes first.

It's safe actually because the functions we created have two arguments
at most. Fix it anyway in case three arguments functions are introduced
in future.

/tmp/build/0e1b53a0/gpdb_src/contrib/dblink/dblink.c: 241 in dblink_connect()

________________________________________________________________________________________________________
*** CID 163942:  Null pointer dereferences  (FORWARD_NULL)
/tmp/build/0e1b53a0/gpdb_src/contrib/dblink/dblink.c: 241 in dblink_connect()
235      * Create a persistent connection to another database
236      */
237     PG_FUNCTION_INFO_V1(dblink_connect);
238     Datum
239     dblink_connect(PG_FUNCTION_ARGS)
240     {
>>>     CID 163942:  Null pointer dereferences  (FORWARD_NULL)
>>>     Assigning: "connstr" = "NULL".
241             char       *connstr = NULL;
242             char       *connname = NULL;
243             char       *msg;
244             PGconn     *conn = NULL;
245             remoteConn *rconn = NULL;
246
Signed-off-by: NAdam Lee <ali@pivotal.io>
Signed-off-by: NYuan Zhao <yuzhao@pivotal.io>

	commit cae7ad90
	Author: Tom Lane <tgl@sss.pgh.pa.us>
	Date:   Mon Sep 22 13:55:14 2008 +0000

	    Fix dblink_connect() so that it verifies that a password is supplied in the
	    conninfo string *before* trying to connect to the remote server, not after.
	    As pointed out by Marko Kreen, in certain not-very-plausible situations
	    this could result in sending a password from the postgres user's .pgpass file,
	    or other places that non-superusers shouldn't have access to, to an
	    untrustworthy remote server.  The cleanest fix seems to be to expose libpq's
	    conninfo-string-parsing code so that dblink can check for a password option
	    without duplicating the parsing logic.

	    Joe Conway, with a little cleanup by Tom Lane