- Add a fault inject to test rollback process
- Remove pg_hba.conf updating during online expand, for only master
  will connect to segment via libpq, master's ip has already been
  in pg_hba.conf

Commit 198f701e forgot to remove these.

CHECK_FOR_INTERRUPTS() had grown quite bloated, given how frequently it runs.
It called IsResQueueEnabled(), which added the overhead of a function call,
even if resource queues were not enabled. If they were enabled, it would
call BackoffBackendTick(), which adds another function call.
BackoffBackendTick() checked a lot of other conditions, so it would still
often not do anything.

It turns out to be cheaper to always increment the "tick" counter, to avoid
the overhead of checking whether we need it or not. Move all the the checks
for whether the whole backoff mechanism is even needed, into a function
that only runs when the tick counter expires.

I've seen those calls take up to 5% of CPU overhead, when profiling some
queries with linux 'perf'. This should shave off the time spent on that.
Reviewed-by: NAshwin Agrawal <aagrawal@pivotal.io>
Reviewed-by: NNing Yu <nyu@pivotal.io>

Operators like HashAgg might need more memory quota than granted.  In
resource group mode this could be allowed as memory can be allocated
from global or per-group shared memory.

By supporting this we improved the support for low-end resgroups, as
long as there is enough shared memory low-end resgroups could still run
large queries although the performance might not be the best.

We need to free up the temporary HLL counters created during HLL merging,
if there are lot of partitions and the data is high for each partition,
we may run into OOM if the temporary counters are not released.

In the merge_leaf_stats function, a nested for loop leaks a single HLL
counter for N^2 iterations (where N = number of partitions). This is run
in a single context, hence leaking considerable memory, leading to VMEM
errors.

This patchs fixes the leaks.
Co-authored-by: NRahul Iyer <riyer@pivotal.io>
Co-authored-by: NAbhijit Subramanya <asubramanya@pivotal.io>

'subqfromlist' field was removed by commit f16deabd.

We had backported this earlier, and got a second copy as part of upstream
merge. Went unnoticed because no one has tried building GPDB on Itanium.

Fumbled this in upstream merge. Harmless, but let's be tidy.

Looking at the historical pre-open-sourcing repository, the 'G' message
was used by ancient prototype code from 2007-2009. The prototype code was
removed in 2009, but this snippet was left over. I don't think it was used
in any released version of GPDB.

The 'W' type message was removed in commit daf6cdbc, but this was left
over.

If the actual signature of the function/variable changes, with an extern
declaration directly in the other .c file, you might not notice. The
correct way to use 'extern', is to have only one 'extern' declaration, in
a header file.

Commit b3c50e40 changed the argument from StringInfo to ErrorData *,
but neglected the comment in the header file about it. Fix, by copying
the up-to-date comment from the .c file.

It was unused, and we don't support Windows as a server platform, anyway.

I think these functions were to implement ALTER TABLE MODIFY RANGE/LIST,
but that command doesn't exist anymore. Not sure if it was ever fully
implemented.

It was always passed as 'true'.

`CdbTryOpenRelation` might return a NULL pointer. Each time we
use the value returned by it we should always check if the
result is NULL. `parserOpenTable` forgot doing such check, this
commit adds the check for NULL.

commit 8eed4217 & e0b06678 allow us to do a gpexpand of GPDB cluster
without a restart, so we called this strategy as "online expand", those
two commits were mainly focus on how to avoid restarting cluster when
expanding cluster, this commit will do the left work to improve gpexpand
using a few features we merged to master recently.

First improvement is, it's no longer necessary to change policy of all
non-partition table to random at the beginning of gpexpand. Previously,
we couldn't tell the difference between expanded table and non-expaned
table, so if the distribution policy of these tables were the same,
planner took these tables's data as co-located and produced a incorrect
plan. To avoid this, gpexpand used to change policy of all table to
random so planner could produce a correct but a non-effective plan,
because random policy always means annoying broadcase motion.

Now each table has a 'numsegments' attribute introduced by 4eb65a53, GPDB
can recognize expanded and non-expand table and produced correct plans. so
the first imporvement is removing the randomization step of tables.

The second improvement is, use a brand new syntax "ALTER TABLE foo EXPAND TABLE"
to focus on the data rebalance of tables. Previously, tables were converted
to randomly before rebalance and numsegments of tables were always the same
with GPDB cluster size, so we can use a tricky "ALTER TABLE foo SET WITH
(REORGNIZE = true) DISTRIBUTED BY (original_key)" command to rebalance data
to new added segments, now policy and numsegments are not changed before
rebalancing data, so expanding such tables is not match the concept of "SET
DISTRIBUTED BY" now, we need a proper syntax to focus on table expanding.

New expand syntax named "ALTER TABLE foo EXPAND TABLE", we have two methods
to do the real data movement inside, one is CTAS, another is RESHUFFLE, which
one is better depends on how much data needs to be moved and whether the table
has index and whether the table is a append only table (analyzed by Hekki).

A drawback of this commit is we always expand a partition within a transaction,
the old behavior is expand the leaf partition in parallel which is faster for
a partition table. We don't allow root partition and its leaf partitions to
have different numsegments for now, this commit disabled the old behavior
temporarily. A topic on how to expanding partition table in parallel is
under discussion and we wish to bring the ability back properly in the feature.

* Refine name quote

Eg: if schema name of table is a.b, table name is c'd, then current gpexpand
cann't handle it.

* docs - foreign data wrapper sql and catalog re page updates

* misc edits

* clarify mpp_execute any value

* docs - remove operator RECHECK; add note, update sys catalog

* add blank line

These are dead references. Just remove them as simple clean up.
Co-authored-by: NJimmy Yih <jyih@pivotal.io>
Co-authored-by: NBradford D. Boyle <bboyle@pivotal.io>

The referred to function is called try_relation_open() and nothing
else. This typo was introduced in 2011 when CdbTryOpenRelation()
was added so it seems about time to correct it.

get_str_from_chunk() is using normal memory management and bypassing
the PostgreSQL memory manager. This means that allocations aren't
automatically guarded by the backend, and it was failing to correctly
check if allocations were successful thus risking a NULL pointer
dereference. Return NULL on out of memory error since there is little
else we can do, and the caller can handle it without dereferencing NULL.

The support for sending alerts via Email or SNMP was quite a kludge,
and there are much better external tools for managing alerts than
what we can supply in core anyways so this retires the capability.

All references to alert sending in the docs are removed, but there
needs to be section written about how to migrate off this feature
in the release notes or a similar location.

Discussion: https://github.com/greenplum-db/gpdb/pull/6384

Extract the first key column's Datum only once, to avoid the
memtuple_getattr / heap_getattr overhead. This is the same optimization we
have in tuplesort.c.
Reviewed-by: NPengzhou Tang <ptang@pivotal.io>
Reviewed-by: NGang Xiong <gxiong@pivotal.io>

Avoid palloc+memcpy for "TC_WHOLE" tuples.
Reviewed-by: NPengzhou Tang <ptang@pivotal.io>
Reviewed-by: NGang Xiong <gxiong@pivotal.io>

More modern, and faster too.
Reviewed-by: NPengzhou Tang <ptang@pivotal.io>
Reviewed-by: NGang Xiong <gxiong@pivotal.io>

Htupfifo is used when parsing incoming messages from the interconnect.
Each UDP message consists of a number of tuple chunks, which form a
number of tuples. When one incoming message is parsed, the htupfifo is
used to hold the tuples formed from the single message.

Typically, each message contains roughly the same number of tuples, so it
is wasteful to palloc/pfree the list node for every tuple. That's why
there is a free list in the FIFO. However, with narrow tuples, one message
can contain hundreds of tuples, which is much more than the built-in max
size on the free list size (10). So in practice, the free list was almost
never enough to cover the need. The message size puts a natural limit on
how large the FIFO can grow, so I don't think we need a limit on the free
list size. Just let it grow as large as needed, and avoid the palloc/pfree
overhead.
Reviewed-by: NPengzhou Tang <ptang@pivotal.io>
Reviewed-by: NGang Xiong <gxiong@pivotal.io>

It was dead code, and we have no plans to resurrect it.
Reviewed-by: NPengzhou Tang <ptang@pivotal.io>
Reviewed-by: NGang Xiong <gxiong@pivotal.io>

The non-MK code was abusing the child's result tuple slot. The
corresponding MK code was changed back in 2010 to not do that, but that
commit missed the non-MK version. This caused a segfault in the
'subselect' regression test. Apparently no one has run the regression
tests with 'gp_enable_motion_mk_sort=off' recently.
Reviewed-by: NPengzhou Tang <ptang@pivotal.io>
Reviewed-by: NGang Xiong <gxiong@pivotal.io>