Fix explain analyze error handling

We used to mark the GUC gp_interconnect_proxy_addresses as
PGC_POSTMASTER, so the cluster must be restarted to reload this setting,
this can be a problem during gpexpand: the cluster expansion itself is
online, but to configure the proxy addresses for the new segments a
restart is needed.

Now we changed it to PGC_SIGHUP, so the setting can be reloaded on
SIGHUP.

Also changed the setting from a developer option to a normal one.

The code will be compiled with ic-proxy enabled, but the tests are still
ran in the default ic-udpifc mode.
Authored-by: NDaniel Gustafsson <dgustafsson@pivotal.io>

Build gpdb binaries with --enable-ic-proxy, and include libuv in the
gpdb packages.

On an ARM64 machine, CREATE EXTENSION pxf_fdw fails with :
ERROR:  the log_errors option cannot be set without reject_limit

In pxf_fdw_validator(), the variable log_errors is declared bool, but
it is initialized with -1. Since bool seems to be now a built-in type,
it's definition is implementation dependent, and it's possible that on
ARM, it is defined as unsigned char. Because, through debugger it
could be seen that log_errors's value is 255 when it was assigned -1.
And because (log_errors != -1) condition returns true, we get the
error "log_errors option cannot be set without reject_limit" even when
log_errors option was not specified while creating the extension.
Due to this, all pxf_fdw tests were failing on ARM64.

If log_errors is specified, set log_errors to true rather than to
defGetBoolean(def) value. And rename log_errors to log_errors_set to
reflect that its purpose is not to store the log_errors value, but
rather to denote whether log_errors option was specified.

Enlarge the sleep time for a query which will be canceled later
to avoid slow execution fails the test.

Normally the test's running time should not get affected since the
sleep query will get terminate immediately.

During testing, I encountered an incremental gprecoverseg hang issue.
Incremental gprecoverseg is based on pg_rewind.  pg_rewind launches a single
mode postgres process and quits after crash recovery if the postgres instance
was not cleanly shut down - this is used to ensure that the postgres is in a
consistent state before doing incremental recovery. I found that the single
mode postgres hangs with the below stack.

\#1  0x00000000008cf2d6 in PGSemaphoreLock (sema=0x7f238274a4b0, interruptOK=1 '\001') at pg_sema.c:422
\#2  0x00000000009614ed in ProcSleep (locallock=0x2c783c0, lockMethodTable=0xddb140 <default_lockmethod>) at proc.c:1347
\#3  0x000000000095a0c1 in WaitOnLock (locallock=0x2c783c0, owner=0x2cbf950) at lock.c:1853
\#4  0x0000000000958e3a in LockAcquireExtended (locktag=0x7ffde826aa60, lockmode=3, sessionLock=0 '\000', dontWait=0 '\000', reportMemoryError=1 '\001', locallockp=0x0) at lock.c:1155
\#5  0x0000000000957e64 in LockAcquire (locktag=0x7ffde826aa60, lockmode=3, sessionLock=0 '\000', dontWait=0 '\000') at lock.c:700
\#6  0x000000000095728c in LockSharedObject (classid=1262, objid=1, objsubid=0, lockmode=3) at lmgr.c:939
\#7  0x0000000000b0152b in InitPostgres (in_dbname=0x2c769f0 "template1", dboid=0, username=0x2c59340 "gpadmin", out_dbname=0x0) at postinit.c:1019
\#8  0x000000000097b970 in PostgresMain (argc=5, argv=0x2c51990, dbname=0x2c769f0 "template1", username=0x2c59340 "gpadmin") at postgres.c:4820
\#9  0x00000000007dc432 in main (argc=5, argv=0x2c51990) at main.c:241

It tries to hold the lock for template1 on pg_database with lockmode 3 but
it conflicts with the lock with lockmode 5 which was held by a recovered dtx
transaction in startup RecoverPreparedTransactions(). Typically the dtx
transaction comes from "create database" (by default the template database is
template1).

Fixing this by using the postgres database for single mode postgres execution.
The postgres database is commonly used in many background worker backends like
dtx recovery, gdd and ftsprobe. With this change, we do not need to worry
about "create database" with template postgres, etc since they won't succeed,
thus avoid the lock conflict.

We may be able to fix this in InitPostgres() by bypassing the locking code in
single mode but the current fix seems to be safer.  Note InitPostgres()
locks/unlocks some other catalog tables also but almost all of them are using
lock mode 1 (except mode 3 pg_resqueuecapability per debugging output).  It
seems that it is not usual in real scenario to have a dtx transaction that
locks catalog with mode 8 which conflicts with mode 1.  If we encounter this
later we need to think out a better (might not be trivial) solution for this.
For now let's fix the issue we encountered at first.

Note in this patch the code fixes in buildMirrorSegments.py and twophase.c are
not related to this patch. They do not seem to be strict bugs but we'd better
fix them to avoid potential issues in the future.
Reviewed-by: NAshwin Agrawal <aashwin@vmware.com>
Reviewed-by: NAsim R P <pasim@vmware.com>

Previously it used max_prepared_xacts for shared snapshot slot number. The
reason that it does not use MaxBackends, per comment, is that ideally on QE we
want to use QD MaxBackends for the slot number, and note usually QE MaxBackends
should be greater than QD MaxBackends due to potential multiple gangs per
query. The code previously used max_prepared_xacts finally for the shared
snapshot slot number calculation. That is not correctly given we have read-only
query, and we have one-phase commit now.  Let's use MaxBackends for shared
snapshot slot number calculation for safety though this might waste some memory.
Reviewed-by: Nxiong-gang <gxiong@pivotal.io>

Previously we assign it as max_prepared_xacts. It is used to initialize some
2pc related shared memory. For example the array shmCommittedGxactArray is
created with this length and that array is used to collect not-yet "forgotten"
distributed transactions during master/standby recovery, but the array length
might be problematic since:

1. If master max_prepared_xacts is equal to segment max_prepared_xacts as
usual.  It is possible some distributed transactions use just partial gang so
the total distributed transactions might be larger (and even much larger) than
max_prepared_xacts. The document says max_prepared_xacts should be greater than
max_connections but there is no code to enforce that.

2. Also it is possible that master max_prepared_xacts might be different than
segment max_prepared_xacts (although the document does not suggest it there is
no code to enforce that),

To fix that we use MaxBackends for the gxact number on master. We may just use
guc max_connections (MaxBackends includes number for autovacuum workers and bg
workers additionally besides guc max_connections), but I'm conservatively using
MaxBackends,  since this issue is annoying - standby can not recover due to the
FATAL message as below even after postgres reboot unless we temporarily
increase the guc max_prepared_transactions value.

2020-07-17 16:48:19.178667
CST,,,p33652,th1972721600,,,,0,,,seg-1,,,,,"FATAL","XX000","the limit of 3
distributed transactions has been reached","It should not happen. Temporarily
increase max_connections (need postmaster reboot) on the postgres (master or
standby) to work around this issue and then report a bug",,,,"xlog redo at
0/C339BA0 for Transaction/DISTRIBUTED_COMMIT: distributed commit 2020-07-17
16:48:19.101832+08 gid = 1594975696-0000000009, gxid =
9",,0,,"cdbdtxrecovery.c",571,"Stack trace:

1    0xb3a30f postgres errstart (elog.c:558)
2    0xc3da4d postgres redoDistributedCommitRecord (cdbdtxrecovery.c:565)
3    0x564227 postgres <symbol not found> (xact.c:6942)
4    0x564671 postgres xact_redo (xact.c:7080)
5    0x56fee5 postgres StartupXLOG (xlog.c:7207)
Reviewed-by: Nxiong-gang <gxiong@pivotal.io>

We need that in more than one test.
Reviewed-by: Nxiong-gang <gxiong@pivotal.io>

ExecChooseHashTableSize() is a hot function which is not only called by executor,
but also by planner. Planner will call this function when calcualting cost for
each join path. The number of join path grow exponentially with the number of
table. As a result, do not using elog(LOG) to avoid generating too many logs.

Commit 362c48b6 added test
concurrent_drop_truncate_tablespace but it never made it to the
schedule.
Co-authored-by: NAlexandra Wang <lewang@pivotal.io>

Our implementations of memory pools have a hidden dependency on _the_
global memory pool manager: typically GPOS_NEW and GPOS_DELETE will
reach for the memory pool manager singleton. This makes GPOS_DELETE on a
memory pool manager undefined behavior because we call member functions
on an object after its destructor finishes.

On the Postgres 12 merge branch, this manifests itself in a crash during
initdb. More concerning is that it only crashed when we set max
connections and shared buffers to a specific number.

GPOS_ASMFP() used x86_64 assembly instructions to get current frame
address. This obviously doesn't compile on other architectures like
ARM64. So instead use __builtin_frame_address(), which is available
in gcc and presumably clang. Since gcc and clang are the two most
common compilers, and since we don't want to support GPORCA on exotic
architectures and compilers, don't bother to use any other way to get
the frame address.

Let configure fail if __builtin_frame_address() is not found, but
don't do this check if gporca is disabled.

GPORCA's CStackDescriptor::Backtrace() uses frame address. But there
is also gp_backtrace() in the backend code that has similar
functionality. This commit does not merge these two places. But it
prepares the infrastructure to do the merge, including a new macro
HAVE__BUILTIN_FRAME_ADDRESS defined in pg_config.h.

Discussion: https://groups.google.com/a/greenplum.org/forum/#!topic/gpdb-dev/FgaR_4sGYrkReviewed-by: NHeikki Linnakangas <hlinnakangas@pivotal.io>

* docs - update utility docs with IP/hostname information.

Add information to gpinitsystem, gpaddmirrors, and gpexpand ref. docs
--Information about using hostnames vs. IP addresses
--Information about configuring hosts that are configured with mulitple NICs

Also updated some examples in gpinitsystem

* docs - review comment updates. Add more information from dev.

* docs - change examples to show valid configurations that support failorver.
Also fix typos and minor edits.

* docs - updates based on review comments.

Add a bool flag 'delim_off' for CopyStateData to indicate if delimiter is set to OFF or not.

* docs - add information for SSL with standby master

--SSL file should not be in $MASTER_DATA_DIRECTORY

Also
--Add not about not using NULL ciphers
--Correct default directory for SSL files to $MASTER_DATA_DIRECTORY

* docs - review comment updates

That's how the locking works for all other tables, including inherited
tables, and for partitions in PostgreSQL v10 partitioning. But in GPDB,
we were intentionally releasing the lock too early, to save memory when
working on huge partition hierarchies I believe. But that's a lousy
tradeoff, we shouldn't skimp on safety just to save some memory. If
you run out of lock memory as a result, you need to bump up
max_locks_per_tranactions. Memory is cheap, and if you're working with
tens of thousands of partitions, you can afford reserving some memory for
the lock manager.

Fixes https://github.com/greenplum-db/gpdb/issues/5919Reviewed-by: NZhenghua Lyu <zlv@pivotal.io>
Reviewed-by: NAsim R P <pasim@vmware.com>

It was used to implement dedup plan which has been
refactored by the commit 9628a332.

So in this commit we remove these unused functions.

The failed test case is to test the command "copy lineitem to '/tmp/abort.csv'"
can be cancelled after COPY is dispatched to QEs. To verify this, it checks that
/tmp/abort.csv has fewer rows than lineitem.

The cancel logical in codes is:

QD dispatched the COPY command to QEs, then if QD get a cancel interrupt, it
sends a cancel request to QEs, however, the QD will keep receiving data from
QEs even QD already get a cancel interrupt. QD relies on QEs to receive the
cancel request and explicitly stop copying data to QD.

Obviously, QEs may already have copied out all data to QDs before they
get cancel requests, so the test case cannot guarantee /tmp/aborted.csv
has fewer rows than lineitem.

To fix this, we just verify the COPY command can be aborted with message
'ERROR:  canceling statement due to user request', the count
verification looks pointless here.

Reader gangs use local snapshot to access catalog, as a result, it will
not synchronize with the sharedSnapshot from write gang which will
lead to inconsistent visibility of catalog table on idle reader gang.
Considering the case:

select * from t, t t1; -- create a reader gang.
begin;
create role r1;
set role r1;  -- set command will also dispatched to idle reader gang

When set role command dispatched to idle reader gang, reader gang
cannot see the new tuple t1 in catalog table pg_auth.
To fix this issue, we should drop the idle reader gangs after each
utility statement which may modify the catalog table.
Reviewed-by: NZhenghua Lyu <zlv@pivotal.io>

General and segmentGeneral locus imply that if the corresponding slice
is executed in many different segments should provide the same result
data set. Thus, in some cases, General and segmentGeneral can be
treated like broadcast.

But what if the segmentGeneral and general locus path contain volatile
functions? volatile functions, by definition, do not guarantee results
of different invokes. So for such cases, they lose the property and
cannot be treated as *general. Previously, Greenplum planner
does not handle these cases correctly. Limit general or segmentgeneral
path also has such issue.

The fix idea of this commit is: when we find the pattern (a general or
segmentGeneral locus paths contain volatile functions), we create a
motion path above it to turn its locus to singleQE and then create a
projection path. Then the core job becomes how we choose the places to
check:

  1. For a single base rel, we should only check its restriction, this is
     the at bottom of planner, this is at the function set_rel_pathlist
  2. When creating a join path, if the join locus is general or segmentGeneral,
     check its joinqual to see if it contains volatile functions
  3. When handling subquery, we will invoke set_subquery_pathlist function,
     at the end of this function, check the targetlist and havingQual
  4. When creating limit path, the check and change algorithm should also be used
  5. Correctly handle make_subplan

OrderBy clause and Group Clause should be included in targetlist and handled
by the above Step 3.

Also this commit fixes DMLs on replicated table. Update & Delete Statement on
a replicated table is special. These statements have to be dispatched to each
segment to execute. So if they contain volatile functions in their targetList
or where clause, we should reject such statements:

  1. For targetList, we check it at the function create_motion_path_for_upddel
  2. For where clause, they will be handled in the query planner and if we
     find the pattern and want to fix it, do another check if we are updating
     or deleting replicated table, if so reject the statement.
  3. Upsert case is handled in transform stage.

Because the variable rel is only used in if (SRF_IS_FIRSTCALL()) branch,
we should move it's declaration into this branch (suggested by Hubert Zhang).

The approach of using a connection string is fragile in the event of an
update to pygresql or missing values, as demonstrated by errors after
update of pygresql in f5758021

Instead, we'll use a named value as arguments to pgdb.connect(),
following the example of dbconn.py
Authored-by: NTyler Ramer <tramer@vmware.com>

Notably we want the shared snapshot dumping information when encountering the
"snapshot collision" error, which was seen on real scenario and it is hard to
debug.

We've seen such a case on a stable release but it is hard to debug via the
message only, so let's provide more details in the error message.

Issue #10069 noted some problems with the linux documentation.

Updating this documentation to be more accurate and direct configuration
steps to the appropriate documentation.
Co-authored-by: NTyler Ramer <tramer@vmware.com>
Co-authored-by: NJamie McAtamney <jmcatamney@vmware.com>

Previously, `cdbpath_dedup_fixup` is the only function that
will invoke `pathnode_walk_node`. And it was removed by the
commit 9628a332.

So in this commit we remove these unused functions.

Remove the set `gp_fts_probe_retries to 1` which may cause FTS probe failed.
This was first added to reduce the test time, but set a lower retry
value may cause the test failed to probe FTS update segment
configuration. Since reduce the `gp_fts_replication_attempt_count` also
save the test time, so skip alter ``gp_fts_probe_retries`.

Also find an assertion may not match when mark mirror down happens before
walsender exit, which will free the replication status before walsender
exit and try to record disconnect info. Which lead the segment crash
and starts recover.

We used to use the option --with-libuv to enable ic-proxy, it is not
staightforward to understand the purpose of that option, though.  So we
renamed it to --enable-ic-proxy, and the default setting is changed to
"disable".

Suggested by Kris Macoskey <kmacoskey@pivotal.io>

Only in proxy mode, of course.  Currently the ic-proxy mode shares most
of the backend logic with ic-tcp mode, so instead of copying the code we
actually embed the ic-proxy specific logic in ic_tcp.c .

It is for the ic-proxy mode.

The interconnect proxy mode, a.k.a. ic-proxy, is a new interconnect
mode, all the backends communicate via a proxy bgworker, all the
backends on the same segment share the same proxy bgworker, so every two
segments only need one network connection between them, which reduces
the network flows as well the ports.

To enable the proxy mode we need to first configure the guc
gp_interconnect_proxy_addresses, for example:

    gpconfig \
      -c gp_interconnect_proxy_addresses \
      -v "'1:-1:10.0.0.1:2000,2:0:10.0.0.2:2001,3:1:10.0.0.3:2002'" \
      --skipvalidation

Then restart to take effect.

It is a preparation for the ic-proxy mode, we need this information to
distinguish a primary segment with its mirror.