Remove unnecessary #includes, add #includes that are actually needed by
some headers.

We always passed CurrentMemoryContext for them, so might as well remove
the parameter, making the code more readable, and always allocate the
return values in CurrentMemoryContext.

These are always compiled directly with C compiler. There's no prospect
of including these in a C++ file.

The correct way is that:

* Every .c file does '#include "postgres.h"', before anything else. After
  that, you can include any system header files (e.g. unistd.h). And after
  that, any other PostgreSQL/GPDB header files.

* Header files should not contain '#include "postgres.h"', as that's done
  in the .c files.

In cdbcat.h, include only the header files that are actually needed for
the single function prototype in that file. And don't include cdbcat.h
unnecessarily. A couple of .c files were including cdbcat.h to get
GpPolicy, but that's actually defined in catalog/gp_policy.h, so #include
that directly instead where needed.

"uint" is not a standard C type, so it might not be available on all
platforms. Indeed, we had a typedef for WIN32 for that. But there's no reason
to use "uint", might as well just use the C standard "unsigned int", or the
PostgreSQL-specific uint32. Makes the intention more clear too, IMHO.

None of the functions declared in cdblogsync exist, nor are used for
anything. cdbanalyze.h didn't contain any prototypes, it just #included
two other headers, so better to #include those directly where needed.

Closes #299.

All patches in this set were either doc commits or already merged except
the moving of the fsync macros from xlog.c to xlogdefs.h. GPDB had already
moved parts to xlog.h so revert these changes and sync with how the macros
are defined upstream.

 Conflicts:
	doc/TODO
	doc/src/FAQ/TODO.html
	doc/src/sgml/func.sgml
	doc/src/sgml/indices.sgml
	src/backend/access/transam/xlog.c
	src/backend/executor/execAmi.c
	src/backend/executor/nodeResult.c
	src/backend/utils/adt/formatting.c
	src/include/executor/nodeResult.h
	src/test/regress/expected/xml.out
	src/test/regress/expected/xml_1.out
	src/test/regress/sql/xml.sql
	src/tools/fsync/test_fsync.c
	src/tools/msvc/Solution.pm
	src/tools/msvc/config.pl

Finding the tle is a case for breaking the loop early but not finding
isn't a failure case. This elog() breaks the following query in the
gp_dqa testcase when found is properly initiated to false before the
loop.

select count(distinct c), count(distinct dt), i from dqa_t1 group by i;

When not initiated at all the variable was likely to not be false
from randomness and the test didnt fail.

Without altering functionality, fix a set of compiler warnings in
gpopt: Properly return in non-void function, remove non-function
invocation of variable and use the right formatter for ULLONG when
printing.

This commit merges a large rewrite of the foreign-key mechanism to properly
enforce the equality check. Instead of selecting an operator named "=" the
equality operator will now be selected from the opfamily of the unique
index that the foreign key depends on. Given how GPDB handles foreign keys
and referential integrity this isn't introducing changes but rather brings
in a good scaffolding for future work.

Other patches are minor spelling fixes on GUCs and some doc changes.

 Conflicts:
	doc/TODO
	doc/src/FAQ/TODO.html
	doc/src/sgml/catalogs.sgml
	doc/src/sgml/trigger.sgml
	src/backend/catalog/aclchk.c
	src/backend/catalog/dependency.c
	src/backend/catalog/index.c
	src/backend/catalog/namespace.c
	src/backend/catalog/pg_constraint.c
	src/backend/catalog/pg_conversion.c
	src/backend/commands/conversioncmds.c
	src/backend/commands/tablecmds.c
	src/backend/commands/trigger.c
	src/backend/commands/typecmds.c
	src/backend/tcop/utility.c
	src/backend/utils/adt/ri_triggers.c
	src/backend/utils/adt/ruleutils.c
	src/backend/utils/cache/syscache.c
	src/bin/pg_dump/pg_dump.c
	src/bin/psql/describe.c
	src/include/catalog/catversion.h
	src/include/catalog/pg_constraint.h
	src/include/utils/rel.h
	src/include/utils/syscache.h
	src/test/regress/expected/alter_table.out
	src/test/regress/expected/foreign_key.out
	src/test/regress/sql/alter_table.sql

A typo caused the planner to not always recognize that the distribution
keys of an outer join match. That would not lead to incorrect results, but
it did lead to unnecessary Motion nodes in some cases.

Fixes issue #340. Thanks @liruto!

For AO/CO tables due to functional nature, new EOF value to be updated
must always be greater than current value. Currently, this check is
performed on persistent table update but it happens as part of Commit-Prepared.
So its super too late to take any action, even if we detect it can only PANIC
the system and already resulted in data corruption for reads as aoseg has been
updated and transaction commited. Hence moving the check while updating the
aoseg table, when such case is detected now transaction can be aborted without
impacting the system or already loaded data in table.

* Remove an unnecessary sleep 2
* Perform the lookup of master hostname only once

This replaces most of the Greenplum code used to ANALYZE a relation with
the upstream implementation.

I did not adopt the upstream block-sampling method of collecting the
sample, however. That would difficult to make work with GPDB, because the
upstream code won't work as is with Append-only tables, and we would also
need to somehow dispatch the block-sampling to all the segments. So the
simplistic "SELECT ... WHERE random() < threshold" method is still used to
collect the sample. However, it's now just a straightforward read-only
query, we no longer create a table to hold the sample, which makes it a lot
cheaper for small tables.

This should make merging with upstream easier. This should also speed up
ANALYZE considerably, as we now collect the sample of rows in one query,
and calculate the stats for each column in-memory, instead of issuing
separate queries for each column.

The test query used system tables pg_class and gp_configuration, which is
fine, except that the cost of scanning pg_class can vary widely, depending
on previous regression tests and the amount of relations created in them.
That made the output of the case a bit unstable; the planner might swap
the inner and outer sides of the nestloop join between pg_class and
gp_configuration, depending on the circumstances. That has been stable
so far, but started to cause grief on another patch I'm working on, which
changes the way ANALYZE works, because apparently it changed the statistics
collected for pg_class sligthly.

To fix, replace pg_class and gp_configuration in the test query with regular
tables, created specifically for the test case. While we're at it, simplify
the query a little bit, and also add a comment explaining what the purpose
of the test is. There doesn't actually seem to be any need to do EXPLAIN
here, the query produces wrong results if the bug is present, so get rid
of that too.

I tested this by reverting the changes that fixed the original bug this test
query was added for, and verifying that the new query also produces wrong
results with that.

Revert the VacAttrStats struct to look the same as in upstream. As a
consequence, we have to also revert the GPDB-specific changes to PostGIS
typanalyze functions. VacAttrStats is part of the public API for
type-specific typanalyze functions, so it's nice to revert that back the
way it is in the upstream, to make custom datatypes written for PostgreSQL
more easily portable to GPDB.

To my surprise, the VacAttrStats struct isn't currently used for anything,
so the changes to it were quite superfluous to begin with. That is to say,
we don't currently use type-specific typanalyze functions at all. That's
about to change, as part of a separate patch I'm working on to revert most
of analyze.c to use upstream code.

Also remove the unused VPgStatisticsStats struct, and the unnecessary
abstraction where VUpdateStats can be either VPgClassStats or
VPgStatisticsStats.

Merge of upstream B-tree split WAL-logging changes, broke the recovery
incase of Btree split. The MirroredLock needs to held while manipulating
buffer.

Coverity pointed out that pszBackupFileName is referenced after free() in
the error path, in dumpDatabaseDefinition(). Testing shows that the
following fprintf() call will also segfault if the file could not be
created. In general, we should not try to continue running if one of these
files could not be created, so add exit_nicely() calls to the error paths.

Removed the locking and some more cleanups.
Avoid looping again in FinishPrepared Transaction. prepare_lsn to commit
the transaction can be found using gxact which we have locked, seems
pointless to loop around again to scan the list.

This is modified patch for GPDB based on postgres patch:
https://github.com/postgres/postgres/commit/bb38fb0d43c8d7ff54072bfd8bd63154e536b384#diff-3ed77c70e54e7f56eff48f6157aba91e
Original Patch commit message:
To lock a prepared transaction's shared memory entry, we used to mark it
with the XID of the backend. When the XID was no longer active according
to the proc array, the entry was implicitly considered as not locked
anymore. However, when preparing a transaction, the backend's proc array
entry was cleared before transfering the locks (and some other state) to
the prepared transaction's dummy PGPROC entry, so there was a window where
another backend could finish the transaction before it was in fact fully
prepared.

To fix, rewrite the locking mechanism of global transaction entries. Instead
of an XID, just have simple locked-or-not flag in each entry (we store the
locking backend's backend id rather than a simple boolean, but that's just
for debugging purposes). The backend is responsible for explicitly unlocking
the entry, and to make sure that that happens, install a callback to unlock
it on abort or process exit.

Not sure why the upstream version didn't print all the same block number
information for B-tree SPLIT_R records that it did for SPLIT_L records,
but seems like an oversight.

https://github.com/snaga/xlogdump.git, commit id
f534a9f6f70ffb691129a9e9ad0b9a85fdef403c

This was intentionally left broken by the merge of upstream B-tree split
WAL-logging changes. Should work now.

We explicitly checked if the subplan was projection-capable, and added
the hash expression ot the subplan's target list if it was. But projecting
the hash expression is not optional, you get a crash if you don't do it. So
instead of doing it only when the subplan is projection-capable, insert a
Result node if needed.

This version changes the spelling of the error message of violating a NOT
NULL-constraint, to match the message of the same error in the executor, so
those differences in regression test expected output can now be reverted.

Most of the patches in this merge were already cherry-picked into GPDB, the
changes merged are a fix for disallowing committing prepared transactions
cross database, followup fixes for the Makefile =/:= patches, an infinite
recursion fix in plan tree dumps and some documentation fixes.

 Conflicts:
	contrib/fuzzystrmatch/fuzzystrmatch.c
	doc/TODO
	doc/src/FAQ/TODO.html
	src/Makefile.shlib
	src/backend/libpq/pqcomm.c
	src/backend/optimizer/README
	src/backend/optimizer/geqo/geqo_eval.c
	src/backend/optimizer/path/joinrels.c
	src/backend/optimizer/plan/initsplan.c
	src/backend/postmaster/postmaster.c
	src/backend/utils/adt/formatting.c
	src/backend/utils/adt/xml.c
	src/backend/utils/error/elog.c
	src/bin/scripts/clusterdb.c
	src/bin/scripts/reindexdb.c
	src/bin/scripts/vacuumdb.c
	src/include/utils/xml.h
	src/interfaces/ecpg/ecpglib/execute.c
	src/port/open.c
	src/tools/msvc/Solution.pm
	src/tools/msvc/clean.bat
	src/tools/msvc/install.pl
	src/tools/msvc/mkvcbuild.pl
	src/tools/msvc/vcregress.bat

Remove the abs() call since ackTime is unsigned (newRTT is as well)
and thus can't be negative.

Also took the liberty of removing comments that doesn't provide any
value to the reader of the code, seems like dead code rather than
documentation.

oldPersistentSerialNum and segmentFileNum are only initalized in the
subsequent loop and printing them before the loop doesn't make any
sense.

This is preceeded by an elog(ERROR ..); call but the compiler will
warn for a potential unitialized use so initialize to InvalidOid
since it is the correct init value anyways.

This is a cherry-pick (with slight massage) of the commit referenced below
which would come eventually in the merge but was trivial enough to fix now.

  commit b2d80147d5a3d0a5815c5b8e63a6fd9cef17f4a7
  Author: Kevin Grittner <kgrittn@postgresql.org>
  Date:   Fri Dec 27 15:41:46 2013 -0600

      Fix misplaced right paren bugs in pgstatfuncs.c.

      The bug would only show up if the C sockaddr structure contained
      zero in the first byte for a valid address; otherwise it would
      fail to fail, which is probably why it went unnoticed for so long.

      Patch submitted by Joel Jacobson after seeing an article by Andrey
      Karpov in which he reports finding this through static code
      analysis using PVS-Studio.  While I was at it I moved a definition
      of a local variable referenced in the buggy code to a more local
      context.

      Backpatch to all supported branches.

This reverts commit 5dd2f280.

This reverts commit b46f781f.

relpages is not updated on master during create index and reindex, as
master need to have agreegated value from segments. As not updating the
relpages, avoid calling RelationGetNumberOfBlocks for master in this
function.

The gpssh utility can have issues during the initial ssh connection
step due to different network configurations that may cause delay.
This commit exposes two key pxssh variables, delaybeforesend and
sync_multiplier, into configurables so that users can change them
as needed to ensure their gpssh works as intended in their network.

Authors: Christopher Hajas and Jimmy Yih