We have new, improved versions of these in src/test/regress. It seems
that TINC will happily use those versions, if we just remove these
old copies from ext.

These are all direct ReleaseSysCache() calls in the upstream.

Move GPDB-specific keywords to a separate section.

The return value was unused, and the 'spin' and 'putInFreeList' argument
were alwasy passed as 'true', which gave the upstream behaviour.

I think these were left out by accident when we cherry-picked the upstream
patches to add location information to various structs.

This reverts commit ce3b3675.

I found these with "callcatcher", written by Caolán McNamara. Many thanks
for the tool! See https://www.skynet.ie/~caolan/Packages/callcatcher.html

Add -H option to disable update gpcrondump history table.
Option '-h' will not be deleted in this release, but it will be deprecated in a future release.

Update behave tests and unit tests.
Modify gpcrondump help file.

Authors: Chumki Roy, Marbin Tan, Nikhil Kak

After commit c63f1b5d, RowExclusiveLock lock on pg_class
won't be held till the end of transaction. Update the expected output file accordingly.

SnapshotNow MUST be used during insert flow to fetch the latest EOF value from
aoseg table. Earlier usage of ActiveSnapshot in AO insert flow caused data
corruption as potentially could read incorrect or stale EOF value from
aoseg. The specific scenario this happens when entry from AppendOnlyHash table
gets evicted out. It invalidates (zeros out) the latestWriteXid and hence
check for usedByConcurrentTransaction cannot be performed. So, any transaction
later inserting data to same AO table, if it has aquired the snapshot and has
latestWriteXid listed in its in-progress distributed transaction list, gets
the same segfile to write. Based on DTM visibility rules using ActiveSnapshot
current transaction will not read the EOF value from previous inserted
transaction as its listed in its in-progress list and hence will overwrite the
data but SnapshotNow will see the latest and make sure to append.

Currenty, there is no easy way to evict entry from appendonly writer hash
table, most of current tests reduce the value of max_appendonly_tables which
needs database restart to take effect and then need to actually create that
many concurrent AO table inserts to evict the hash table entry. Using this
GUC can easily tests the eviction behavior.

Currently, during insert to AO/CO tables check is performed to validate
file-offset (EOF) found from pg_aoseg which would be used to start writing
the data to file. The offset to start writing needs to be greater than
currently marked EOF in persistent table. The validation is currently
performed for all other scenarios except EOF=0, so this commit is modifing to
enable it for EOF-0 case as well. As it was seen in field for yet to be known
reasons maybe indexing issues on pg_aoseg table, that incorrect EOF=0 was
fetched from aoseg and valid data was over-written. So, this protection will
prevent data-loss scenarios.

This commit adds gpperfmon/logs/ to the exclusion list and also corrects
gp_dumps/ to db_dumps/ which gpinitstandby sends as args to pg_basebackup to
initialize the standby master. This should speed up gpinitstandby if a user
uses gpperfmon/gpcc or gpcrondump.

Authors: Amil Khanzada and Jimmy Yih

gp_dbid gp_num_contents_in_cluster gp_contentid
-b is being used upstream for binary upgrade mode.
The rest because of future conflict issues. The long options will always work

Also updated gp_optimizer expected output and ignore line number
difference for functions.c

We don't use CaQL here anymore. Fix to match upstream.

We don't use CaQL here anymore.

We just got rid of the last users of them.

To reduce our diff vs upstream, to make diffing and merging easier.

It's a plain heap tuple in the usptream. This reduces the diff vs.
upstream.

Use a regular syscache lookup like in the upstream, and get rid of the
now-unused get_func_namespace function.

While it might make sense to extract this duplicated code to a function,
let's rather avoid the difference from upstream.

FTS doesn't actually seem to use the superuser's username for anything.
That allowed removing probeUser and retrieveUserAndDb(). All the remaining
calls to FtsFindSuperuser() were from cdbresynchronizechangetracking.c,
but all of those callers just discarded the return value.
FtsFindSuperuser() doesn't throw any errors, either, so it didn't serve
any error-checking purpose either. Remove it all.

Not that it matters from a performance point of view, but surely it was
not intended.

We just looked up the relation with RangeVarGetRelidExtended(). There's
no reason to believe it might've been removed since then, especially
when we just locked it.