Current generate_series cost more memory than before, so
we decrease the series size to make the test pass.

If a target list entry is found under a relabelnode, the newly created
var node should be nested inside the relabelnode if the vartype
of the var node is different than the resulttype of the relablenode.
Otherwise, the cast information is lost and executor will complain type mismatch
	```sql
	CREATE TABLE t1 (a varchar, b character varying) DISTRIBUTED RANDOMLY;
	SELECT array_agg(f)  FROM (SELECT b::text as f FROM t1 GROUP BY b) q;
	ERROR:  attribute 1 has wrong type (execQual.c:763)  (seg0 slice2 127.0.0.1:25432 pid=7064)
	DETAIL:  Table has type character varying, but query expects text.
	```

Previously there is a restriction on GUC 'max_resource_groups'
that it cannot be larger than 'max_connections'.
This restriction may cause gpdb fail to start if the two GUCs
are not set properly.
We decide to decouple these two GUCs and set a hard limit
of 100 for 'max_resource_groups'.

This commit introduces the gp_recursive_cte test file with a variety of
tests concentrated on exercising referencing a recursive CTE in a
subquery

Not having EXECUTE keyword here, makes EXPLAIN EXECUTE not formatted as explain
plans and causes failures.

Brings in ORCA changes to support partition elimination with IDFs in the
partition predicate. Also update tests.

In Greenplum 5.0, OID and relfilenode were decoupled. Each QD and QE
segment was given its own relfilenode counter (similar to the nextOid
counter) which users could manually set (with extreme caution!) by
using pg_resetxlog tool. The pg_resetxlog --help output did not
display the flag to set the relfilenode counter which was missed from
that patch. Now it should properly display as an available option.

Reference:
https://github.com/greenplum-db/gpdb/commit/1fd11387d2b9f250c14f0ccb893c0956b1bf1487

Thanks to Marbin Tan for reporting this issue.

When including or excluding schemas in gpcrondump, functions may be
 dumped that require a procedural language to be created upon restore.
 However, languages are not part of any schema, so they are not already
 included in such a filter.

 This commit changes the behavior of gp_dump to always dump procedural
 languages when including and excluding schemas.  It still will not
 dump them when including or excluding tables.
Signed-off-by: NKaren Huddleston <khuddleston@pivotal.io>

Upstream commit 220db7cc replaced all the idiomatic DirectFunctionCalls
of textin/textout, to use these new handy macros instead. Do the same
for all the remaining such calls in GPDB-specific code.

A slot maybe reused on QE while its still using by another QE which
might causes runtime error. This issue exists for a long time in theory,
but the fail rate is enlarged with a current commit 8005f559.

To workaround the issue we change the free slot pool from a stack into a
queue, slots are allocated from the head and freed to the tail, so a
slot will not be reused immediately after being freed.

In worst case all the in-use slots are not freed in time on QEs, so we
also doubled the slot pool size to have enough free slots for new
queries even in such a worst case.

In any sense this is not a fix, just a quick workaround, we will keep
working on this race condition issue. Once a root fix is ready this
workaround will be replaced.

Don't transform large array Const into ArrayExpr for Orca (#3406)

If the number of elements in the array Const is greater than
optimizer_array_expansion_threshold, returns the original Const unmodified.
Otherwise, it will cause severe performance issue for Orca optimizer for array
with very large number of elements, e.g. 50K.

Fixes issue #3355
[#151340976]

Explain analyze with explain_memory_verbosity set to 'detail' or 'summary' will show total memory used accross slices

We will be adding an extra line detailing total memory used across slices to explain analyze. This will help us in
profiling memory usage from TPC-DS benchmark.

```
(slice0)    Executor memory: 322K bytes.  Peak memory: 11783K bytes.  Vmem reserved: 12288K bytes.
   (slice1)    Executor memory: 8375K bytes avg x 3 workers, 8375K bytes max (seg0).
  Peak memory: 9488K bytes avg x 3 workers, 9488K bytes max (seg0).  Vmem reserved: 9216K bytes avg x 3 workers, 9216K bytes max (seg0).
 Total memory used across slices: 40247K  bytes
 Statement statistics:
   Memory used: 128000K bytes
```
Signed-off-by: NSambitesh Dash <sdash@pivotal.io>

* resgroup: provide helper function to wakeup a proc.
* resgroup: provide helper function to check resWaiting.
* resgroup: refine the logic in ResGroupWaitCancel().
* resgroup: error out in ResGroupHashFind() directly.
* resgroup: error out in ResGroupHashRemove() directly.
* resgroup: add an arg `grant` in wakeupSlots().
* resgroup: move resWaiting updates into WaitQueue helper funcs.
* resgroup: cleanup the duplicate wakeup logic in ResGroupSlotRelease().
* resgroup: fix typo in function name groupAssignChunks().
* resgroup: rename groupAssignChunks() to groupRebalanceQuota().
* resgroup: polish comments for groupApplyMemCaps().
* resgroup: add comments for ResGroup{Caps,Opts}.
* resgroup: cleanup obsolete declarations in resgroup.h
* resgroup: use int32 instead of uint32 for self->memUsage.
* resgroup: correct the slot cleanup in ResGroupWaitCancel().
* resgroup: do not error out in transaction callbacks.

These tables seem dead and were only used before 4.0 era, hence removing them
now from catalog.

The runaway query TINC tests occasionally encounter issues where a
gpstop -ar is not successfull because of open connections. This commit
ensures that at the least gpstop will always restart gpdb.
Signed-off-by: NEkta Khanna <ekhanna@pivotal.io>

Previously every resource group has its own slot pool, each with size of 'MaxConnection'.
In order to reduce memory usage, implement a slot pool shared by all resource groups.

In addition, free slots in the slot pool are organized as a free list to optimize alloc/free
operations.

In copyFuncs(), the fallthrough for SpecialJoinInfo was unintentionally
done as a part of subselect merge.  This commit fixes that along with
adding support for new fields in copyFuncs(), outFunc() and equalFunc()

[Ref #151491231]
Signed-off-by: NDhanashree Kashid <dkashid@pivotal.io>

Previously this test's result and plan was wrong. Now, Orca is fixed to
produce a valid plan along with the correct result.

Bump Orca version to 2.46.3

After 7e268107 started seeing warnings like
------------------
cdbgroup.c:1478:68: warning: expression which evaluates to zero treated as a null pointer constant of type 'List *' (aka 'struct List *') [-Wnon-literal-null-conversion]
                result_plan = (Plan*)make_motion_gather_to_QE(root, result_plan, false);
                                                                                 ^~~~~
------------------

After commit 1822c826 started seeing bunch of
warnings like
-------------------------------------------
memaccounting.c:247:1: warning: no previous prototype for function 'MemoryAccounting_DeclareDone' [-Wmissing-prototypes]
MemoryAccounting_DeclareDone()
^
../../../../src/include/utils/memaccounting.h:238:1: note: this declaration is not a prototype; add 'void' to make it a prototype for a zero-parameter function
MemoryAccounting_DeclareDone();
^
                             void
memaccounting.c:263:1: warning: no previous prototype for function 'MemoryAccounting_RequestQuotaIncrease' [-Wmissing-prototypes]
MemoryAccounting_RequestQuotaIncrease()
^
../../../../src/include/utils/memaccounting.h:241:1: note: this declaration is not a prototype; add 'void' to make it a prototype for a zero-parameter function
MemoryAccounting_RequestQuotaIncrease();
^
                                      void
2 warnings generated.
ext_alloc.c:35:1: warning: no previous prototype for function 'Ext_OptimizerAlloc' [-Wmissing-prototypes]
Ext_OptimizerAlloc(size_t size)
^
ext_alloc.c:50:17: warning: unused variable 'account' [-Wunused-variable]
        MemoryAccount *account = MemoryAccounting_ConvertIdToAccount(ActiveMemoryAccountId);
                       ^
ext_alloc.c:48:1: warning: no previous prototype for function 'Ext_OptimizerFree' [-Wmissing-prototypes]
Ext_OptimizerFree(void *ptr)
^
ext_alloc.c:59:1: warning: no previous prototype for function 'GetOptimizerOutstandingMemoryBalance' [-Wmissing-prototypes]
GetOptimizerOutstandingMemoryBalance()
^
-------------------------------------------

As part of commit efed2fcc new walrep state was
added 'n' (not-in-sync). The toolkit function gp_pgdatabase__() needs to be
modified as well to check for that state.

Original code not using #defines but direct characters like 's', 'c' makes it
very tricky find stuff in code. Hopefully, future chnages would be easy to spot
and make.

QE detach resource group slot at the end of transaction, the
last QE of the slot release the slot, and release the overused
memory if resource group config has been changed.

commit 07b9936a
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Fri Feb 27 23:30:29 2009 +0000

    Temporarily (I hope) disable flattening of IN/EXISTS sublinks that are within
    the ON clause of an outer join.  Doing so is semantically correct but results
    in de-optimizing queries that were structured to take advantage of the sublink
    style of execution, as seen in recent complaint from Kevin Grittner.  Since
    the user can get the other behavior by reorganizing his query, having the
    flattening happen automatically is just a convenience, and that doesn't
    justify breaking existing applications.  Eventually it would be nice to
    re-enable this, but that seems to require a significantly different approach
    to outer joins in the executor.

Added relevant test case.
Signed-off-by: NDhanashree Kashid <dkashid@pivotal.io>

Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Tue Jul 8 14:03:32 2014 -0400

    While the x output of "select x from t group by x" can be presumed unique,
    this does not hold for "select x, generate_series(1,10) from t group by x",
    because we may expand the set-returning function after the grouping step.
    (Perhaps that should be re-thought; but considering all the other oddities
    involved with SRFs in targetlists, it seems unlikely we'll change it.)
    Put a check in query_is_distinct_for() so it's not fooled by such cases.

    Back-patch to all supported branches.

    David Rowley

(cherry picked from commit 2e7469dc8b3bac4fe0f9bd042aaf802132efde85)

Signed-off-by: NJemish Patel <jpatel@pivotal.io>

Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Tue Dec 10 16:10:36 2013 -0500

An expression such as WHERE (... x IN (SELECT ...) ...) IN (SELECT ...)
could produce an invalid plan that results in a crash at execution time,
if the planner attempts to flatten the outer IN into a semi-join.
This happens because convert_testexpr() was not expecting any nested
SubLinks and would wrongly replace any PARAM_SUBLINK Params belonging
to the inner SubLink.  (I think the comment denying that this case could
happen was wrong when written; it's certainly been wrong for quite a long
time, since very early versions of the semijoin flattening logic.)

Per report from Teodor Sigaev.  Back-patch to all supported branches.

(cherry picked from commit 884c6384a2db34f6a65573e6bfd4b71dfba0de90)

commit 0a0ca1cb18a34e92ab549df171e174dcce7bf7a3
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Sat Mar 24 16:22:00 2012 -0400

    Fix planner's handling of outer PlaceHolderVars within subqueries.

    For some reason, in the original coding of the PlaceHolderVar mechanism
    I had supposed that PlaceHolderVars couldn't propagate into subqueries.
    That is of course entirely possible.  When it happens, we need to treat
    an outer-level PlaceHolderVar much like an outer Var or Aggref, that is
    SS_replace_correlation_vars() needs to replace the PlaceHolderVar with
    a Param, and then when building the finished SubPlan we have to provide
    the PlaceHolderVar expression as an actual parameter for the SubPlan.
    The handling of the contained expression is a bit delicate but it can be
    treated exactly like an Aggref's expression.

    In addition to the missing logic in subselect.c, prepjointree.c was failing
    to search subqueries for PlaceHolderVars that need their relids adjusted
    during subquery pullup.  It looks like everyplace else that touches
    PlaceHolderVars got it right, though.

    Per report from Mark Murawski.  In 9.1 and HEAD, queries affected by this
    oversight would fail with "ERROR: Upper-level PlaceHolderVar found where
    not expected".  But in 9.0 and 8.4, you'd silently get possibly-wrong
    answers, since the value transmitted into the subquery wouldn't go to null
    when it should.