Fix fts_recovery_in_progress test failure because pg_rewind runs before timeline id updating after mirror promotion.

This issue was actually seen on PG upstream and was fixed by Heikki in
pg_rewind test case. In gpdb, we are much more automatically using pg_rewind
via gprecoverseg, so we'd better fix that in our own code (gprecoverseg or
pg_rewind). On gpdb, after mirror promotion via fts, the time is possibly not
short before a correct timeline id is flushed into the pg_control file. For
such case, if we do incremental recovery via gprecoverseg, it will succeed but
the target node (new mirror) is still not functional.

commit 484a848a
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date:   Thu Apr 30 21:57:18 2015 -0700

    Fix pg_rewind regression failure after "fast promotion"

    pg_rewind looks at the control file to determine the server's timeline. If
    the standby performs a "fast promotion", the timeline ID in the control
    file is not updated until the next checkpoint. The startup process requests
    a checkpoint immediately after promotion, so this is unlikely to be an
    issue in the real world, but the regression suite ran pg_rewind so quickly
    after promotion that the checkpoint had not yet completed.

    Reported by Stephen Frost

Without this commit, after initdb datfrozenxid for all databases
remains 3. Ideally, databases should get freezed during initdb as
tools like pg_upgrade make assumptions on the same.
Co-authored-by: NEkta Khanna <ekhanna@pivotal.io>

* docs - first HA updates that use WAL replication.

--Removed references to filerep
--Updated segment instance states to use WAL rep states
--Other misc. updates.

* docs -  HA updates for WAL replication - review comment upates

Merge the two concepts, squelching and eager-freeing. There is now only
one function, ExecSquelchNode(), that you can call. It recurses to
children, as before, but it now also performs eager-freeing of resources.
Previously that was done as a separate call, but that was an unnecessary
distinction, because all callers of ExecSquelchNode() also called
ExecEagerFree()

The concept of eager-freeing still lives on, as ExecEagerFree*() functions
specific to many node types. But it no longer recurses! The pattern is
that ExecSquelchNode() always performs eager freeing of the node, and also
recurses. In addition to that, some node types also call the node-specific
EagerFree function of the same node, after reaching the end of tuples.

This makes it more clear which function should be called when.

ExecEagerWalker() used to have special handling for the pattern of:
  Result
  -> Material
    -> Broadcast Motion

I tried removing that, but then I started to get "illegal rescan of motion
node" errors in the regression tests, from queries with a LIMIT node in a
subquery. Upon closer look, I believe that was because the Limit node was
calling ExecSquelchNode() on the input, even though the Limit node was
marked as rescannable. To fix that, I added delayEagerFree logic to Limit
node, to not call ExecSquelchNode() when the node might get rescanned
later.

The planstate_walk_kids() code did not know how to recurse into the
children of a MergeAppend node. We missed adding that logic, when we
merged the MergeAppend node type from upstream, in 9.1. We don't use that
mechanism for recursing in ExecSquelchNode() anymore, but that probably
should be fixed, anyway, as a separate commit later.

Fixes https://github.com/greenplum-db/gpdb/issues/6602 and
https://github.com/greenplum-db/gpdb/issues/6074.
Reviewed-by: NTang Pengzhou <ptang@pivotal.io>

The test was testing, that when ExecEagerFree() is called on a
ShareInputScanState node, it calls ExecEagerFreeShareInputScan(). But that
is trivially true, there is a direct call to ExecEagerFreeShareInputScan()
in ExecEagerFree(). Seems pointless to have a test for it.

Mostly misspellings of "function".

TemplateDbOid is for database template1, but template1 could be recreated and
thus its oid is not longer TemplateDbOid.

Also change to Use database postgres to find database oid and tablespace like
what fts and gdd do. We should better use the same database for such
purpose. I thought about which database gpdb should use: template1 or
postgres. Both of them are template database, but it seems that some users
or customers sometimes customize their own template1 database and
template1 is the default template for database creating so if some auxiliary
processes use that, "create database" command will fail. Using database
postgres seems to be more reasonable. In addition, of course, users possibly
drop the database postgres, but that is a rare case and they could easily
recreate one for our purpose. We really do not need to over-design for such rare case.

Serializable is not yet supported, so we need to fallback gucs
'transaction_isolation' and 'default_transaction_isolation' from
serializable to repeatable read. Before, we just right fallback the
transaction_isolation. For default_transaction_isolation, we only use
the correct fallback when using the ‘SET SESSION CHARACTERISTICS AS
TRANSACTION ISOLATION LEVEL serializable’ statement. But we do not
fallback when using 'SET default_transaction_isolation = 'serializable''.
Add a check hook 'check_DefaultXactIsoLevel' to fix it.

We know the number of Motion nodes upfront, so we can allocate the
'mnEntries' array to the right size when we create the motion layer. No
need to expand it incrementally.
Reviewed-by: NTang Pengzhou <ptang@pivotal.io>

* Adds window examples to query topic in admin guide

* Fix some clear errors in CREATE TYPE and CREATE FUNCTION SQL

* Changes from review comments

* Add missing period

We tried changing the docker image for the open source compile job and
discovered that libzstd-devel wasn't installing. The issue was that
libzstd comes from epel-release, so epel-release had to be installed
first. The existing docker image already has epel-release installed so
this issue never manifested.

Since the existing code looked like it was trying to install each
package with a separate yum command, we opted to make it actually do
that to fix this issue.

We also removed openssl-libs and perl-Env because they don't exist in
any repositories we have and the installation failed when we switched to
using separate yum installs.
Co-authored-by: NKaren Huddleston <khuddleston@pivotal.io>
Co-authored-by: NBen Christel <bchristel@pivotal.io>

In order to be rendered as checkboxes by Github, the square brackets
need a space between them.
Co-authored-by: NTaylor Vesely <tvesely@pivotal.io>
Co-authored-by: NBen Christel <bchristel@pivotal.io>

Back when the initial backport of pg_upgrade was added to Greenplum
we included a small dump of a 4.3.x cluster for testing purposes.
This cluster was inadequate for testing pg_upgrade back then, and is
even more so today. Remove to reduce potential confusion that these
files are actually part of the now quite extensive test harness for
pg_upgrade in Greenplum. The cluster also requires access to a 4.3
cluster which is a licensed product, so remove from the open source
repository.

Discussion: https://github.com/greenplum-db/gpdb/pull/6149Reviewed-by: NJim Doty <jdoty@pivotal.io>
Reviewed-by: NJacob Champion <pchampion@pivotal.io>

This removes unused arguments to cdbparallelize(), tidies up incorrect
comments and converts an Insist(0) call to an elog().

Discussion: https://github.com/greenplum-db/gpdb/pull/6423Reviewed-by: NAshwin Agrawal <aagrawal@pivotal.io>

The segment role GP_ROLE_UNDEFINED should never be set, and cdbvars
is guarding against that ever happening. Thus, testing for it in the
code makes it look like it could indeed happen which is misleading
to the reader. Remove the test and refactor the switch() to instead
use an if-else clause with an assertion that maintains the same
guarantee as the previous coding did.

Discussion: https://github.com/greenplum-db/gpdb/pull/6423Reviewed-by: NAshwin Agrawal <aagrawal@pivotal.io>

Variable 'maybe_local_equijoin' is added by GPDB and not used any more.
Reviewed-by: NHeikki Linnakangas <hlinnakangas@pivotal.io>

* docs - update analyzedb --skip-root-partition for incremental analyze (HLL)

doc update until analyzedb is updated to account for incremental analyze.

* docs - update analyzed - clarify --skip_root_stats description.

* docs - new GUC optimizer_enable_agg_skew_avoidance

* docs - edits for GUC optimizer_enable_agg_skew_avoidance

* docs - change GUC name to optimizer_force_agg_skew_avoidance

* docs - discuss the global deadlock detector

* some of the edits requested by david

* move opening paragraph to release note

* reorg content, add a bit about local deadlock

* guc can be reloaded

* concurrent update AND DELETE

This change brings back an optimization to reuse buffer when slot's
PRIVATE_tts_memtuple is NULL and PRIVATE_tts_mtup_buf is not. Here we
pass inline_toast=false into memtuple_form_to. Thus previous refactor to
detoast either MemTuple or HeapTuple in SendTuple is maintained
(from commit bf5e3d5d).

This got duplicated by accident in the 9.4.20 merge (commit f2e08026).

These calls are made in the caller, ReadBufferExtended(), now. These
are just leftovers.

These happen often, when we have backported some upstream commits, and
later merge the same commits the second time, as part of the PostgreSQL
merge.

These were left unused by commit 5ab222943d.

This was accidentally added as part of the PostgreSQL 9.4 merge. I was
hacking on commit faf0ec6b at the same time as the 9.4 merge, and this
slipped into the 9.4 merge branch, and from there into master with the
merge.

The code that used to create these paths was removed in commit d4ce0921,
but this was left behind.

The only place where it was read was in setting the number of segments,
when marking the resulting plan as "strewn". We can use the 'input_locus'
directly for that, because that's where the numsegments value for the
'output_locus' came from in every case.
Reviewed-by: NNing Yu <nyu@pivotal.io>
Reviewed-by: NJesse Zhang <jzhang@pivotal.io>

We used to call some node types different names in EXPLAIN output,
depending on whether the plan was generated by ORCA or the Postgres
planner. Also, a Bitmap Heap Scan used to be called differently, when the
table was an AO or AOCS table, but only in planner-generated plans. There
was some historical justification for this, because they used to
be different executor node types, but commit db516347 removed last such
differences.

Full list of renames:

Table Scan -> Seq Scan
Append-only Scan -> Seq Scan
Append-only Columnar Scan -> Seq Scan
Dynamic Table Scan -> Dynamic Seq Scan
Bitmap Table Scan -> Bitmap Heap Scan
Bitmap Append-Only Row-Oriented Scan -> Bitmap Heap Scan
Bitmap Append-Only Column-Oriented Scan -> Bitmap Heap Scan
Dynamic Bitmap Table Scan -> Dynamic Bitmap Heap Scan

This merges upto upstream commit 4f0bf335 (tag: REL9_4_20).
Co-authored-by: NAshwin Agrawal <aagrawal@pivotal.io>
Co-authored-by: NEkta Khanna <ekhanna@pivotal.io>
Co-authored-by: NJinbao Chen <jinchen@pivotal.io>
Co-authored-by: NPaul Guo <pguo@pivotal.io>
Co-authored-by: NRichard Guo <riguo@pivotal.io>
Co-authored-by: NShaoqi Bai <sbai@pivotal.io>

Commit 305f7bd8 removed 'gp_enable_adaptive_nestloop' (which was
already unused at that point), but missed it in the config file.

Now that filerep is gone, it shouldn't be necessary anymore. Clarify
the way 'lockHolderProcPtr' is cleared, while we're at it.

These happen often, when we have backported some upstream commits, and
later merge the same commits the second time, as part of the PostgreSQL
merge.

We don't support compiling the server on Windows. Even if we did, I think
much of these wouldn't be needed.

It was always set to same value as 'numConns'. I guess there was some idea
of also connecting to mirrors with the interconnect, but that hasn't been
used for a long time.