Use the standard initdb mechanism for it, instead of having bespoken code
in gpinitsystem.

Also remove the unnecessarily complicated logic to generate gp_toolkit.sql
from gp_toolkit.sql.in. All the JETPACK_* variables were constants, and
there is particular need in making the gp_toolkit functions relocatable to
different schemas or prefixes, so just hardcode them and remove the sed
magic.

Rewrite the file header of gp_toolkit.sql. The legal blurp is not needed,
make the header look more like that of information_schema.sql and
system_views.sql.

Remove compaction_info.sql. It was only needed for old in-place
upgrade from 4.3.x to 4.3.4.2, which is not relevant for master branch.

Fix the "jetpack" bugbuster regression test. It was originally written to
test the gp_toolkit views, but gp_toolkit was in fact not installed in
bugbuster, and the expected output just contained a bunch of "relation
does not exist" errors. Now it actually tests gp_toolkit again. Some of
the test queries didn't produce repeateable results, due to differing oids,
differences in table sizes, and other tables created by previous tests, so
fixed those too.

This has a small user-visible difference: gp_toolkit schema is now also
installed in template0. That caused the difference in the expected outputs:
pg_regress creates the "regression" database using template0 as the
template, so gp_toolkit used to not be installed in it, but it is now.

Just some random things I happened to spot while reading code.

Picked up by clang using -Wheader-guard.

Fixed a small typo and ensured consistency of whitespace etc.

Compiler warned about these. Commit 50e67f10 removed the only callers
of these functions.

This is to fix intermittent failures due to 'too many clients'
error when the test is run with a large parallel group.

Closes #222.

Commit 9e25d97f changed the .sql file, but forgot to change the expected
outpout.

* Add 'const' to arguments of some functions. While we're at it, remove the
duplicate extern declaration of FaultInjector_InjectFaultIfSet from
gpdbdefs.h.

* pstrdup() constants passed to makeString(). I think the lack of copy
was harmless, but makeString() explicitly says that the caller should make
a copy, and all other callers seem to obey that, so better safe than sorry.

Removing ALTER LANGUAGE test as it's conflicting with a
different test, specifically functions.sql.

The hack was put in place, because prodataaccess values for these functions
are wrong in the catalogs. They should be marked as READS SQL DATA, but
they're marked as NO SQL. However, there are many more functions that are
similarly marked incorrectly, so we really should go through the pg_proc
catalog and fix all of them. But I'll leave that for another patch.

ORCA doesn't actually pay any attention to the prodataaccess field. It used
to to use it for optimization purposes at some point, but the code was taken
out because most functions are indeed mislabeled, and it was causing
problems.

This hack was subtly wrong anyway: the functions were marked as set
returning functions in the hard-coded structs, but they're not in fact
set-returning.

While we're at it, remove hardcoded OID of count() aggregate function, and
include it from pg_proc.h instead.

Previously, if the set of tables to be restored using gpdbrestore --truncate
included a table that did not exist in the target database, gpdbrestore would
raise an exception when attempting to truncate the nonexistent table.  Now,
gpdbrestore displays a warning regarding the nonexistent table, and the table is
restored normally.

Authors: Jimmy Yih and James McAtamney

securitypolicy needs to be aware of classpath
added test to pljava

1) read int@int_16 as short, not int
2) write short as int@int_16, not int
3) support read int as short

Fix gpdiff.pl issues caused by processing init_file multiple times; also add verbose option for gpdiff.pl

resolved #209

These configure options used to control whether to build PL/Java and PL/R,
but the build system works differently now, and the options don't exist
in the server's configure script anymore.

Not sure why we these were listed, but AFAICS they're not used for
anything.

This code and bug was in 1f4ad703, and it
caused an "operator XXX is not a valid ordering operator" error.

The 'sortop' field in SortClause and GroupClause needs to be an ordering
operator, i.e. the "<" operator, while we use the "=" operator to represent
grouping in other places. Need to be careful to convert between the two
in right places.

Add a few tests for this in the gp_dqa test case. This was reproducible by
the existing queries, when you coerce the planner to choose sort+group
aggregates instead of hash aggregates.

User could use VARIADIC to specify parameter list when defining UDF
if they want to use variadic parameters. It is easier for user to write
only one variadic function instead of same name function with different
parameters. An example for using variadic:
create function concat(text, variadic anyarray) returns text as $$
select array_to_string($2, $1);
$$ language sql immutable strict;

select concat('%', 1, 2, 3, 4, 5);

NOTE: The variadic change set is ported from upstream of PostgreSQL:
commit 517ae403
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Thu Dec 18 18:20:35 2008 +0000

Code review for function default parameters patch.  Fix numerous problems as
per recent discussions.  In passing this also fixes a couple of bugs in
the previous variadic-parameters patch.

commit 6563e9e2
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Wed Jul 16 16:55:24 2008 +0000

Add a "provariadic" column to pg_proc to eliminate the remarkably expensive
need to deconstruct proargmodes for each pg_proc entry inspected by
FuncnameGetCandidates().  Fixes function lookup performance regression
caused by yesterday's variadic-functions patch.

In passing, make pg_proc.probin be NULL, rather than a dummy value '-',
in cases where it is not actually used for the particular type of function.
This should buy back some of the space cost of the extra column.

commit d89737d3
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Wed Jul 16 01:30:23 2008 +0000

Support "variadic" functions, which can accept a variable number of arguments
so long as all the trailing arguments are of the same (non-array) type.
The function receives them as a single array argument (which is why they
have to all be the same type).

It might be useful to extend this facility to aggregates, but this patch
doesn't do that.

This patch imposes a noticeable slowdown on function lookup --- a follow-on
patch will fix that by adding a redundant column to pg_proc.

Conflicts:
	src/backend/gpopt/gpdbwrappers.cpp

SET command is session effective, all existed idle gangs should be set for later reuse,
but for busy gangs declared by cursors, errors occur if they receive a set command. Way
to fix it is marking busy gangs to no reuse so they can be destroyed after cursors been
closed.

Heikki suggested that we backport atomic operation from PostgreSQL 9.5 to
fix this

    commit b64d92f1
    Author: Andres Freund <andres@anarazel.de>
    Date:   Thu Sep 25 23:49:05 2014 +0200

    Add a basic atomic ops API abstracting away platform/architecture details.

    Several upcoming performance/scalability improvements require atomic
    operations. This new API avoids the need to splatter compiler and
    architecture dependent code over all the locations employing atomic
    ops.

    For several of the potential usages it'd be problematic to maintain
    both, a atomics using implementation and one using spinlocks or
    similar. In all likelihood one of the implementations would not get
    tested regularly under concurrency. To avoid that scenario the new API
    provides a automatic fallback of atomic operations to spinlocks. All
    properties of atomic operations are maintained. This fallback -
    obviously - isn't as fast as just using atomic ops, but it's not bad
    either. For one of the future users the atomics ontop spinlocks
    implementation was actually slightly faster than the old purely
    spinlock using implementation. That's important because it reduces the
    fear of regressing older platforms when improving the scalability for
    new ones.

    The API, loosely modeled after the C11 atomics support, currently
    provides 'atomic flags' and 32 bit unsigned integers. If the platform
    efficiently supports atomic 64 bit unsigned integers those are also
    provided.

    To implement atomics support for a platform/architecture/compiler for
    a type of atomics 32bit compare and exchange needs to be
    implemented. If available and more efficient native support for flags,
    32 bit atomic addition, and corresponding 64 bit operations may also
    be provided. Additional useful atomic operations are implemented
    generically ontop of these.

    The implementation for various versions of gcc, msvc and sun studio have
    been tested. Additional existing stub implementations for
    * Intel icc
    * HUPX acc
    * IBM xlc
    are included but have never been tested. These will likely require
    fixes based on buildfarm and user feedback.

    As atomic operations also require barriers for some operations the
    existing barrier support has been moved into the atomics code.

    Author: Andres Freund with contributions from Oskari Saarenmaa
    Reviewed-By: Amit Kapila, Robert Haas, Heikki Linnakangas and Álvaro Herrera
    Discussion: CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com,
        20131015123303.GH5300@awork2.anarazel.de,
        20131028205522.GI20248@awork2.anarazel.de

For OSX commercial builds, instruct the gcc compiler to produce
i686 (CPU) instructions.  This is needed to support an upstream
PostgreSQL merge which uses atomic instructions introduced in one of
those later CPUs.

Previously, there was no autoconf test for those instructions, and we
just compiled hand-crafted assembly to use those instructions anyway,
even though the rest of the compiler was targeting the older cpus.

reference: https://wiki.gentoo.org/wiki/GCC_optimization#-march

  Different CPUs have different capabilities, support different
  instruction sets, and have different ways of executing code. The
  -march flag will instruct the compiler to produce specific code for
  the system's CPU, with all its capabilities, features, instruction
  sets, quirks, and so on.

Authors: James McAtamney and Jimmy Yih