This reverts commit 1596d323 since
it broke cluster startup, clearly it needs more attention before
being ready.

This puts on on par with upstream PostgreSQL 9.1.20, released on
2016-02-11, for tzdata and the below referenced commit. The reason
for not updating further is that there are tzdata format changes
in 9.1.21, 2016a is the last release we can import without merging
code changes as well.

  commit 6887d72d06a2f36508d5be9cca316088d4c60b26
  Author: Tom Lane <tgl@sss.pgh.pa.us>
  Date:   Fri Feb 5 10:59:09 2016 -0500

    Update time zone data files to tzdata release 2016a.

    DST law changes in Cayman Islands, Metlakatla, Trans-Baikal Territory
    (Zabaykalsky Krai).  Historical corrections for Pakistan.

This bumps the copyright years to the appropriate years after not
having been updated for some time.  Also reformats existing code
headers to match the upstream style to ensure consistency.

The linenumbers are prone to change (and ideally shouldn't be there
at all since we should use ereport instead), so scrub them from the
test output with a matchsubs rule. The recent changes for copyright
notices broke this since it added a line to the file.

The missing errcode makes the ereport call include the line number
of the invocation from the .c file, which not only isn't too useful
but cause the tests to fail on adding/removing code from the file.

* Use ereport() with a proper error code, rather than elog(), so that you
  don't get the source file name and line number in the message, and the
  serious-looking backtrace in the log.

* Remove the hint that advised "SET gp_enable_segment_copy_checking=off",
  when a row failed the check that it's being loaded to the correct
  segment. Ignoring the mismatch seems like very bad idea, because if
  your rows are in incorrect segments, all bets are off, and you'll likely
  get incorrect query results when you try to query the table.

When define index concurrently, DefineIndex() commits current transaction and
dispatch a command to segments without resource group info, therefore, QE get
a capability info with zero configured, the problem is groupReleaseMemQuota()
use the empty capability info wrong and caused a floating-point exception.

According to the code, it should use prevSharedInfo->caps instead

-1 is a valid value for errordata_stack_depth until errstart() has
been called which inits the stack. In correct usage it's thus fine
to use it as an array subscript without inspecting it, since demote
and dismiss are useless outside an error context. Incorrect usage
would however cause a memory error so guard against that since it's
the right thing to do.

strncpy() can render the buffer non-NULL terminated on input which
is MAXPGPATH characters long. This is not only incorrect code, it's
a mismerge since upstream has never used strncpy here, but strlcpy.
Fix by replacing with strlcpy calls, thus aligning us with upstream
better as well.

The num_cwords member was left blank which cause issues for the
freeing function which operates based on its value.

{f}stat() can fail and reading the stat buffer without checking for
status is bad hygiene. Ensure to always test return value and take
the appropriate error path in case of stat error.

Iff the value isn't a varlena, then dataLen and dataStart won't be
set but we may still come to inspect them later on. Avoid reading
uninitialized variables by zeroing them in that case and check for
that before reading.

The strncpy() will make path2 non-NULL terminated in the (rare?)
cases where filespaceLocation2 is MAXPGPATH chars long. Use strlcpy
instead like other places in the codepath does and ensure we always
have a NULL terminated string.

Current FTS probe relies on file replication data structures mostly
found in pmModuleState.  This commit establishes an empty FTS probe
response packet that primaries using segment WAL replication can fill
out later.

We also introduce the 'w' fault_strategy (WAL replication) to replace
the 'f' fault_strategy (file replication).

This commit is carved and modified from a previously closed PR:
https://github.com/greenplum-db/gpdb/pull/2936

Authors: Abhijit Subramanya and Jimmy Yih

* 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

Rather than appending to a StringInfo, return a string. The caller can
append that to a StringInfo if he wants to. And instead of passing a
prefix as argument, the caller can prepend that too.

Both callers passed the same format string, so just embed that in the
function itself.

Don't append a trailing "; ". It's easier for the caller to append it,
if it's preferred, than to remove it afterwards.

Also add a regression test for the 'gp_enable_fallback_plan' GUC. There
were none before. The error message you get with that GUC disabled uses the
gp_guc_list_show function.

Plus other minor cleanup.

The locking contract to access LSN of a page is:
1. Content lock must be held in exclusive mode,
OR
2. Content lock must be held in shared mode and buffer header spinlock
must be held.

PageGetLSN() and BufferGetLSNAtomic() now assert that this contract is
maintained for shared buffers. To make the implementation for
PageGetLSN() a little easier, move to a static inline function instead
of a macro. Callers passing a PageHeader must now explicitly cast to
Page.
Signed-off-by: NAsim R P <apraveen@pivotal.io>
Signed-off-by: NAshwin Agrawal <aagrawal@pivotal.io>

Certain callers of PageGetLSN weren't correctly holding the buffer
spinlock; it is needed whenever the buffer content lock is not held in
exclusive mode.

For heapam.c, also ensure that we don't access the LSN after releasing
the lock.
Signed-off-by: NAsim R P <apraveen@pivotal.io>

Most, if not all, of the queries in the qp_olap_windowerr test, contained
gpdiff "mvd" directives, to tell gpdiff what the expected order of output
rows is. However, all of the queries in that test fail on purpose, because
of varios errors. That means that the "mvd" directives didn't do anything,
because there were not result sets in the output.

However, commit de548159, added a few tests that return a result set,
to the end of the test script. That caused the preceding "mvd" directives
to be applied, incorrectly, to those new result sets. That produced a lot
of messages like "specified MVD column out of range: 3 vs 1" in the
console. While harmless, they didn't cause the test to fail, let's be tidy.

'nuff said.

1. Add dependency packages to Ivy
2. Modify set_bld_arch.sh to correctly recongize aix7
3. Disable unsupported python libraries on aix7.
4. Disable gpmapreduce for aix7
5. Set ADDON_DIR for aix7
   Signed-off-by: Peifeng Qiu pqiu@pivotal.io

Original commit message:

This speeds up reassigning locks to the parent owner, when the transaction
holds a lot of locks, but only a few of them belong to the current resource
owner. This is particularly helps pg_dump when dumping a large number of
objects.

The cache can hold up to 15 locks in each resource owner. After that, the
cache is marked as overflowed, and we fall back to the old method of
scanning the whole local lock table. The tradeoff here is that the cache has
to be scanned whenever a lock is released, so if the cache is too large,
lock release becomes more expensive. 15 seems enough to cover pg_dump, and
doesn't have much impact on lock release.

Jeff Janes, reviewed by Amit Kapila and Heikki Linnakangas.

It was getting in the way of backporting commit 9b1b9446f5 from PostgreSQL,
which added an '#include "storage/lock.h"' to resowner.h, forming a cycle.

The include was only needed for the decalaration of awaitedOwner global
variable. Replace "ResourceOwner" with the equivalent "struct
ResourceOwnerData *" to avoid it.

This revealed a bunch of other files that were relying on resowner.h
being indirectly included through lock.h. Include resowner.h directly
in those files.

The ResPortalIncrement.owner field was not used for anything, so instead
of including resowner.h in that file, just remove the field that needed
it.

An FTS probe to the primaries in a mirrorless cluster will never
result in the update of gp_segment_configuration.  If a primary goes
down, we must keep the primary marked as up so that gpstart can start
the primary back up.  All transactions will abort and nothing should
work except for read-only queries to master-only catalog tables.

Stopping the FTS probes for mirrorless cluster introduced an infinite
loop in FtsNotifyProber in which the dispatcher waits in an infinite
loop for fts_statusVersion to change.  To break the infinite loop, we
acknowledge the forced probe request as a no-op and update
fts_statusVersion to break the loop for the dispatcher.  The
dispatcher should then act same as before this commit.

We also add #define for character value of GpFaultStrategy.

Authors: Xin Zhang, Ashwin Agrawal, and Jimmy Yih

We believe the pipeline is red due to this commit:
https://github.com/greenplum-db/gpdb/commits/fdc9e0a2812dbb01f0883c570f90d82397e2c573

The PR pipeline is red when it was pushed:
https://github.com/greenplum-db/gpdb/pull/3089

Some unreentrant functions are invoked in signal handler.

To fix this bug: change signal handler to asynchronous modle.

using global variable "sig_flag" to store last signal state,every 1s polling or
after failed happen in block IO function(such as send/ receive) check "sig_flag".

  fix bug : gpload does not stop after informatica sends exit call

    Some unreentrant functions are invoked in signal handler.

    To fix this bug: change signal handler to asynchronous modle.

    using global variable "sig_flag" to store last signal state,every 1s polling or
    after failed happen in block IO function(such as send/ receive) check "sig_flag".

Introduced by commit 522c7c09, spotted by Coverity.

In PostgresQL, the DO block is after RemoveFuncStmt. It was slightly
misplaced when it was backported from PostgreSQL 9.0.

Any error that the user is expected to see should be using the
ereport() macro rather than its older cousin elog(). Also avoid
closing resources just before erroring out as the error cleanup
will be handled automatically, and move a long message to have
an errhint instead.

In binary swap test, new binary is replaced by old binary and then run
pg_dump, however, pg_dump will still try to load new regress.so, so if
regress.so contain new symbols only belong to new binary, it will report
an error. For resGroupPalloc() ifself, IsResGroupEnabled or
IsResGroupActivated make no much difference, so to make binary swap pass,
we still use IsResGroupEnabled.

I'm not sure if we broke this during the 8.3 merge, or if it was broken
even before that, but our version of heap_form_tuple was confused over
what the isnull argument is. The difference between heap_form_tuple()
and heap_formtuple() is the values used in the "isnull" array, but
our heap_form_tuple passed a 'char' array to the internal heap_fill_tuple()
function, which assumes a 'bool' arry.

That caused an assertion failure in hstore regression tests (and almost
certainly a crash or at least wrong results without assertions, though I
didn't check.)

To fix, take the version of heap_form_tuple() from PostgreSQL 8.4, which
converts the 'char' array to a 'bool' array, and then calls the new
heap_formtuple() function.

SPIMemReserved was initialized in CreateSharedMemoryAndSemaphores which
make no sense, this commit put it under InitResManager where the resource
memory policy is set.

As a pleasent side-effect, the window specification in a
"func_expr OVER (window_spec)" rule now gets its parse location set
correctly. Thanks to that, a few error messages now give a user-friendly
error location line.

GPDB 5 doesn't have the pg_get_functiondef server function needed by \ef,
so it doesn't work.

Fixes github issue #3076.

This is a backport of an upstream commit that conveniently fixes this:

commit 2463f5da3ccd67b266ee7a9b8c0906221a501b9e
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Thu Nov 10 18:37:05 2011 -0500

    Throw nice error if server is too old to support psql's \ef or \sf command.

    Previously, you'd get "function pg_catalog.pg_get_functiondef(integer) does
    not exist", which is at best rather unprofessional-looking.  Back-patch
    to 8.4 where \ef was introduced.

    Josh Kupershmidt

The resource group is enabled but not initialized on auxiliary processes
and special backends like ftsprobe and filerep, previously we performed
resource group operations no matter resource group is initialized or not
which leads to some unexpected error.