That seems like a very random place to do it (sorry for the pun). The
random seed is initialized at backend startup anyway, that ought to be
good enough, so just remove the spurious initialization from bfz.c.

In the passing, improve the debug-message to mention which compression
algorithm was used.

I guess once upon a time this was needed to get better error messages,
with error positions, but we rely on the 'location' fields in the parse
nodes nowadays. Removing this doesn't affect any of the error messages
memorized in the regression tests, so it's not needed anymore.

* Simplify tuple serialization in Motion nodes.

There is a fast-path for tuples that contain no toasted attributes,
which writes the raw tuple almost as is. However, the slow path is
significantly more complicated, calling each attribute's binary
send/receive functions (although there's a fast-path for a few
built-in datatypes). I don't see any need for calling I/O functions
here. We can just write the raw Datum on the wire. If that works
for tuples with no toasted attributes, it should work for all tuples,
if we just detoast any toasted attributes first.

This makes the code a lot simpler, and also fixes a bug with data
types that don't have a binary send/receive routines. We used to
call the regular (text) I/O functions in that case, but didn't handle
the resulting cstring correctly.

Diagnosis and test case by Foyzur Rahman.
Signed-off-by: NHaisheng Yuan <hyuan@pivotal.io>
Signed-off-by: NNing Yu <nyu@pivotal.io>

While we don't bother doing this on every commit that makes
catalog-incompatible changes, let's at least do it one time, now that
5X_STABLE has been branched. We ought to have done this at the time that
the branch was created, but better late than never.

Discussion: https://groups.google.com/a/greenplum.org/d/msg/gpdb-dev/ybFrXcIWNOQ/lx1JSdvcAAAJ

Some non-reentrant functions are invoked in the signal handler.

To fix this bug: change signal handler to the asynchronous model.

using global variable "sig_flag" to store last signal state, every 1s polling or
after failed happen in block IO function(such as send/ receive) check "sig_flag".

These are just pro forma, as the location field isn't used for anything
after parse analysis, but let's be tidy.

Only a top-level transaction can have a distributed transaction ID, so
this seems more logical.

When adding the GPTest version printing it become clear that not
only was the existing version printing broken, the options parsing
was too. See sample execution below:

  ./get_ereport.pl -version
  Use of uninitialized value $ARGV[0] in pattern match (m//) at ./get_ereport.pl line 99.
  Missing argument in sprintf at ./get_ereport.pl line 163.
  ./get_ereport.pl version 0.

So while in there, this commit fixes both. The options are now
properly parsed with GetOptions() using pass_through and the version
printed using the GPTest module.

The perl code in src/test/regress was using a mix of either not
printing the version, printing it wrong (due to us not using CVS
anymore) or using a hardcoded string. Implement a new module for
common test code called GPTest.pm which abstracts this (for now
it's the only thing it does but this might/will change, hence the
name). The module is created by autoconf to make it pull in the
GP_VERSION from there.

While there, simplify the version output in gpdiff which included
the version of the system diff command - somewhat uninteresting
information as it's not something that changes very often and just
cluttered up the output.

This removes the MakeMaker support but since we have no intention
of packaging these programs into a CPAN module it seems pointless
to carry that format around.

regress.c is an upstream file, and all Greenplum additions can
cause conflicts as we merge with PostgreSQL. This refactors all
GPDB specific code into a new file, regress_gp.c, to keep the
upstream file as close to upstream as possible (with backports).
The new file gets compiled and loaded just like regress.c, so
no change in how it works.

Also remove an unused function, perform rudimentary codereview
on the Greenplum tests and massage regress.c slightly to make
it closer to upstream.

There are same codes computing target segment in both function CopyFrom
and CopyFromDispatch. Extract the codes into separate functions.
Signed-off-by: NXiaoran Wang <xiwang@pivotal.io>

Planner and ORCA translator both implemented the same logic, to assign
external table URIs to segments. But I spotted one case where the logic
differed:

CREATE EXTERNAL TABLE exttab_with_on_master( i int, j text )
LOCATION ('file://@hostname@@abs_srcdir@/data/exttab_few_errors.data') ON MASTER FORMAT 'TEXT' (DELIMITER '|');

SELECT * FROM exttab_with_on_master;
ERROR:  'ON MASTER' is not supported by this protocol yet.

With ORCA you got a less user-friendly error:

set optimizer=on;
set optimizer_enable_master_only_queries = on;
postgres=# explain SELECT * FROM exttab_with_on_master;
ERROR:  External scan error: Could not assign a segment database for external file (CTranslatorDXLToPlStmt.cpp:472)

The immediate cause of that was that commit fcf82234 didn't remember to
modify the ORCA translator's copy of the same logic. But really, it's silly
and error-prone to duplicate the code, so modify ORCA to use the same code
that the planner does.

This backports the new FUNCDETAIL_WINDOWFUNC return code from PostgreSQL
8.4, and refactors the code to match upstream, as much as feasible. A few
error scenarios now give better error messages.

Simpler that way.

We don't need two different functions to check whether an expression
contains a window function. Replace both with the variant used in
the upstream, contain_window_function().

This allows having error positions for more syntax errors, and reduces
the diff footprint of our window functions implementation against the
one in PostgreSQL 8.4.

As AssignResGroupOnMaster() is called before the transaction is
actually started, so the failure won't cause transaction abort,
we need handle the error to prevent slot leaking.
Signed-off-by: NZhenghua Lyu <zlv@pivotal.io>

Most notably, move the definition of XmlExpr and friends to where they are
in the upstream.

Also move the function to where it is in the upstream.

To reduce our diff footprint.

There was only one caller, and it provided no memory pool. The fault
injection was also unused AFAICS.

Also, no need to have separate readfuncs.c and readfast.c copies of
_readFuncCall, as they were identical.

This slightly reduces the amount of GPDB-specific changes in xlog.c, which
is nice because that file is huge.

GPDB's pg_dump only supports dumping from server versions based on
PostgreSQL 8.2 and above, while PostgreSQL's pg_dump supports much older
versions. In GPDB's version, many of the version checks to deal with
older versions had been removed, but that caused a lot of diffs against
upstream, because of changed indentation.

To reduce our diff footprint, put back those versions checks. But actually
trying to deal with very old server versions seems futile, so instead of
resurrecting all the code, just put an error message into the branches
where upstream e.g. constructs queries that work with older versions. The
version checks should never actually fail, because we check the server
version once at the beginning of pg_dump. But it's nice to have something
in those branches, to document the fact that there was more code there in
the upstream, and to keep the formatting the same as in upstream.

Includes changing the --help message for --insert option slightly, to match
upstream. In the upstream, this change was made already in version 8.2, but
was missed in GPDB for some reason.

A window frame where the "lead" and "trail" are the same, i.e something like
"XXX() OVER (w BETWEEN 1 ROWS PRECEDING AND 1 ROWS PRECEDING", is pretty
useless in practice, so it seems uninteresting to optimize for it. Better to
keep the code simple.

When extensions were introduced in PostgreSQL, a call to
recordDependencyOnCurrentExtension() was added in the creation codepath
of all the object types. However, external protocols is a GPDB-specific
object type, and we missed making that change there.

Fixes github issue #2942.

Backport to 5X_STABLE, in order to make backporting future fixes easier.

I meant to remove this in previous commit already, but forgot to "git add".

Commits 563c8c6b and 96e6f19d removed most of this dead
infrastructure, but had to leave these in place to avoid catalog change.
Now that catalog changes are OK again, complete the removal.

This includes the changes from upstream commit 096a30b5, to silence
compiler warnings. We had already silenced them by initializing the
variables elsewhere, but let's stick to upstream code wherever possible.

Only ParseFuncOrColumn needed the additional "isstrict" and "isordered"
return values from func_get_detail. And even ParseFuncOrColumn only needed
that information under certain circumstances, for error checks. Move the
code to fetch that information out of func_get_detail, to separate
little helper functions.

In principle, fetching the "isstrict" and "isordered" flags separately is
more expensive, because it now requires two syscache lookups rather than
one. In practice, however, this is a win, because you only need to fetch
the "isstrict" flag if a FILTER clause was given, and you only need the
"isordered" flag if an OVER clause was given. Both of those clauses are
rare, so in the common case this actually saves one syscache lookup. (None
of this matters much in practice, though, because syscache lookups are
pretty cheap anyway.)

The upstream code isn't quite identical to ours, but it's the same
functionality. Now it's at least in the same place.

This makes constructing strings a lot simpler, and less scary. I changed
many places in GPDB code to use the new psprintf() function, where it
seemed to make most sense. A lot of code remains that could use it, but
there's no urgency.

I avoided changing upstream code to use it yet, even where it would make
sense, to avoid introducing unnecessary merge conflict.

The biggest changes are in cdbbackup.c, where the code to count the buffer
sizes was most really complex. I also refactored the #ifdef USE_DDBOOST
blocks so that there is less repetition between the USE_DDBOOST and
!USE_DDBOOST blocks, that should make it easier to catch bugs at compilation
time, that affect the !USE_DDBOOST case, when compiling with USE_DDBOOST,
and vice versa. I also switched to using pstrdup instead of strdup() in
a few places, to avoid memory leaks. (Although the way cdbbackup works,
it would only get launched once per connection, so it didn't really matter
in practice.)

Seems better for the function to palloc the struct it returns, rather than
have it fill in a struct provided by the caller.

The thing that really caught my eye was this:

```
genericPair *genpair = (genericPair *) palloc0 (4 * sizeof(char *));
```

That wrorks, because the genericPair struct consists of four "char *"
fields. But it seems fragile, should use "sizeof(genericPair)". This commit
fixes that, among the other kibitzing.