Gpcrondump and gpdbrestore redirect stderr into status file for segments,
errors should be reflected into the master's report file.
Warnings will be given if process completed but errors were generated in
the report file.

Also made some refactor of the code.

This commit also reverts 08f4ada7.

Authors: Pengcheng Tang, Nikhil Kak

Fix the compiler warning introduced by commit:
08f4ada7

Author: Heikki Linnakangas

Usage: minirepro <database> [options]

Options:
  --version             show program's version number and exit
  -?, --help            Show this help message and exit
  -h HOST, --host=HOST  Specify a remote host
  -p PORT, --port=PORT  Specify a port other than 5432
  -U USER, --user=USER  Connect as someone other than current user
  -q QUERY_FILE         file name that contains the query
  -f OUTPUT_FILE        minirepro output file name

Closes #157.

Gpcrondump and gpdbrestore redirect stderr into status file for segments,
errors should be reflected into the master's report file.
Warnings will be given if process completed but errors were generated in
the report file.

Also made some refactor of the code.

Authors: Pengcheng Tang, Nikhil Kak

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

This patch replaces all occurrences of pgsql-bugs@postgresql.org with
bugs@greenplum.org. Pointers to the pgsql-bugs mailinglist in the code
remain as they re. Regression and BugBuster tests are also patched.

There are a bunch of backend files that are never mocked, but always linked
into test program as is. List those in Makefile.mock, so that every Makefile
doesn't need to list them. Makes the makefiles simpler, and you need less
boilerplate code when adding a new test program.

Not all of these backend files were listed in the _REAL_OBJS variable of
every test, but in those tests that they were not, they were also not used,
so it doesn't matter if we use the real or mock version.

This way we don't need to link the whole backend into client mock programs.
We've gotten away with it so far, but it would cause clashes if one of the
client programs contained a function or global variable with same name as
in the backend. And of course it's completely unnecessary anyway.

The typo is from the dumping based on object types(i.e,
index/function/trigger/table/data), but currently gpdb
does not support this feature ported from postgres.

Initially planned to remove the related dead code, but
as we do the merge of the upstream postgres, I decide to
save the code to minimize the diff and effort in case
we want to support such in future.

This patch merges the PostgreSQL 9.5 implementation of SSE4.2 into GPDB.
The SSE4.2 implementation was lifted right out of PostgreSQL without
change to make merging later PostgreSQL releases easier.

Update win32 configuration to support SSE4.2 runtime checks

This change was pulled from "src/include/pg_config.h.win32" from the
commits below.

configure.in changes, determining if cpu instruction for perfomring runtime
checks are availible, and moving some of the code to port SSE4.2 came from the
following PostgreSQL commits:

commit 3dc2d62d
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date:   Tue Apr 14 17:05:03 2015 +0300

    Use Intel SSE 4.2 CRC instructions where available.

    Modern x86 and x86-64 processors with SSE 4.2 support have special
    instructions, crc32b and crc32q, for calculating CRC-32C. They greatly
    speed up CRC calculation.

    Whether the instructions can be used or not depends on the compiler and the
    target architecture. If generation of SSE 4.2 instructions is allowed for
    the target (-msse4.2 flag on gcc and clang), use them. If they are not
    allowed by default, but the compiler supports the -msse4.2 flag to enable
    them, compile just the CRC-32C function with -msse4.2 flag, and check at
    runtime whether the processor we're running on supports it. If it doesn't,
    fall back to the slicing-by-8 algorithm. (With the common defaults on
    current operating systems, the runtime-check variant is what you get in
    practice.)

    Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.

commit b4eb2d16
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date:   Tue Apr 14 19:56:00 2015 +0300
	On gcc and clang, the _mm_crc32_u8 and _mm_crc32_u64 intrinsics are not
	defined at all, when not building with -msse4.2. But on icc, they are.
	So we cannot assume that if those intrinsics are defined, we can always use
	them safely, we might still need the runtime check.

	To fix, check if the __SSE_4_2__ preprocessor symbol is defined. That's
	supposed to be defined only when the compiler is targeting a processor that
	has SSE 4.2 support.

	Per buildfarm members fulmar and okapi.

I removed everything else from gpupgrade earlier, but missed this file
for reason.

Currently gpdbrestore does not allow tables to be restored from one schema to another.
Eg:
testschema.testtable => anotherschema.testtable

Commit 9114c65f moved dumping
tablespaces under the -F option to ensure that tablespaces would
only be dumped when the filespaces upon which they depended were
dumped.  It was decided that, for backwards compatibility, the
original behavior would be restored.

Authors: Jimmy Yih and James McAtamney

The current plan is to use something like pg_upgrade for future in-place
upgrades. The gpupgrade mechanism will not scale to the kind of drastic
catalog and other data directory layout changes that are coming as we
merge with later PostgreSQL releases.

Kept gpupgrademirror for now. Need to check if there's some logic that's
worth saving, for a possible pg_upgrade based solution later.

Oops, missed these in the FDW-removal commit.

It was just syntax and catalogs, you couldn't actually do anything useful
with it. Remove it, so that we have less code to maintain, until it's time
to merge this stuff from upstream again when we merge with PostgreSQL 8.4.
It's probably easier to merge this back at that point than maintain this
backported version in the meanwhile. Less effort now, until we reach that
point, and once we get to the point in 8.4 that we merge this in, we'll
have all the preceding patches applied already, so it should merge quite
smoothly.

until we change the catalog. specifically pg_enum typarray, and
ev_enabled

tgconstraint has been added to the pg_trigger catalog

This makes merging and diffing with upstream easier. There were so many
GPDB-added GUCs in guc.c that "git merge" didn't handle it very well, and
you easily got merge conflicts that were error-prone to fix manually.

I kept a few GUCs in guc.c that are not present in REL8_2_0, because they
were backported from later PostgreSQL versions, rather than being
completely GPDB-specific.

Clean up the diff between guc.c and upstream, by removing unnecessary
includes, reordering a few GUCs to match upstream better, and similar
cosmetic changes.

I had to move MAX_KILOBYTES from guc.c to guc_tables.h, because guc_gp.c
needs it too. I also had to export assign_msglvl() function from guc.c, so
that it can be called from other assign_* functions from guc_gp.c. And I
had to add the code to process the ConfigureNames*_gp arrays in addition
to the upstream ones. These things increase the diff against upstream, but
not by too much, IMHO. I also copy-pasted constants like MS_PER_S and
KB_PER_MB, which seems safe as those are natural constants, and should
never change.

  1) Short flags for output file and dumping filespaces were erroneously both assigned to -f.
     Dumping filespaces is now properly assigned to -F.
  2) Tablespaces were being dumped even when filespaces flag was not set.
     Now, tablespaces are only dumped when their corresponding filespaces are dumped.

Authors: Jimmy Yih and James McAtamney

During a restore on a database without the related schemas (ex. --redirect
to empty database) in which these schemas are set to be dropped, the SET
search_path can be missing before the CREATE TABLE statements in the dump
file. This results in tables being restored in the default schema instead
of their expected schema.

The main issue was that the ArchiveHandle->currSchema was not being reset
when drop schema prior to create was requested in gp_dump. The
ArchiveHandle->currSchema is now properly reset. This was originally fixed
in upstream Postgres, and this commit just ports over that fix to gp_dump.

When the segment dump process crashes, master ends up waiting
infinitely. So adding a fault detection mechanism to periodically
check if the segment dump process is alive.

Fix DDBoost restore to retrieve dump file from Data Domain Server;

DDBoost restore incorrectly assumes that the post schema dump file is
located locally, and failed the restore process.

Gpcrondump now sets the correct schema for schema altered sub partition tables;

If sub partition tables got altered and set to different schema,
gpcrondump incorrectly sets the schema for these modified tables.

Fix the usage of fmtId() to correctly consume the returned value;

fmtId() reuses the same buffer; so before calling fmtId() for the 2nd time,
consume the value in the returned buffer.

Fix restore failure when exchange partition with external tables has 'LOG ERRORS' statement.

If an external table has a "LOG ERRORS" statement in the definition, it explicitly
creates the error table. Hence, restore fails due to name conflicts with the subpartition table name.

Authors : Pengcheng Tang, Nikhil Kak, Isobel Redelmeier

There are no translations for Greenplum-specific strings, so it seems like
a disservice to allow anyone to build with --enable-nls.

The PostgreSQL translation files were a bit of a hodge-podge too; they
seemed to be from PostgreSQL 8.4.1, but we still carried the bunch of
incomplete translations that were removed in PostgreSQL 8.4.1. Let's not
pretend that there's any sense in them, and just remove all .po files. If
we want to make NLS to work properly in the future, we can bring them back,
using some sensible versions. Another option would've been to replace them
with the REL8_2_0 versions, which would possibly have made merging with
upstream slightly easier, as you wouldn't get merge conflicts on the
removed files, but those conflicts are easy to deal with. Also, by removing
the files completely, we don't need to decide what to do with the
references to pgsql-bugs@postgresql.org in them (we're trying to replace
all those references with bugs@greenplum.org).

Now that we no longer forcibly compile strlcpy.c, and only compile and link
it into strlcpy.o into libpgport when needed, this is no longer needed.
Furthermore, it caused the linking to fail on platforms that don't need
strlcpy.o, like OS X.

When user runs \d or \d+ on a partition table, it will display partition
keys on the current level for the partition table with the clause of
'Partition by: (partition_key_1, ..., partition_key_n)' after
'Distributed by' clause. But if user runs \d or \d+ on a non-partition
table or leaf level partition table, the 'Partition by' clause will not
be displayed.

Haisheng Yuan
Closes #25

Based on patch by Raymond Barbiero

columns procost and prorows, to allow simple user adjustment of the estimated
cost of a function call, as well as control of the estimated number of rows
returned by a set-returning function.  We might eventually wish to extend this
to allow function-specific estimation routines, but there seems to be
consensus that we should try a simple constant estimate first.  In particular
this provides a relatively simple way to control the order in which different
WHERE clauses are applied in a plan node, which is a Good Thing in view of the
fact that the recent EquivalenceClass planner rewrite made that much less
predictable than before.

Previously, disabled triggers were not displayed any differently than
enabled ones, which was quite misleading. Patch from Brendan Jurd.

rather than a value too high.

HTML in HTML mode. Patch from Jeremy Drake.

L Bayuk

Euler Taveira de Oliveira