It was quite clearly broken, as it didn't do anything with the new_tle
that it chased up, and the end result was just the same as calling
canonicalize_pathkeys() on the input.

I'm not 100% the code is doing the right thing even with this: If the
pathkey's operator family doesn't match the join clause's operator family,
the output isn't truly ordered the same way. This is not an issue for the
case that I included in the regression test, where the join happens on a
constant, but I can't figure out whether this might be an issue with some
other query.

The comment in apply_shareinput_xslice() said that we process top-plan
first, to ensure that we find the producer of a shared scan before its
consumers, when the top plan contains a producer for subplans. But the
situation can just as well be the other way 'round.

No new test case added, because running the existing with_clause test
with gp_cte_sharing=on trips the assertion.

Fixes github issue #287.

int2vector and aclitem don't have B-tree operators, making them not
mergejoinable. In the merge of the equivalence classes patch, I made
cdb_make_pathkeys_for_expr() more strict on that, and it now throws
an error if it's passed a datatype that doesn't have a mergejoinable
= operator. It used to return a path key with InvalidOid as the sort
operator, but that seems like a recipe for bugs elsehere.

To fix, mandate that all gpdb-hashable datatypes must be mergejoinable.
int2vector and aclitem are not, so forbid using them in DISTRIBUTED BY.

This is a backwards-incompatible change, but hopefully no-one is using
int2vector or aclitem in user-tables, at least not as a distribution key.

This is dead, because SubPlan is an Expr node and therefore cannot appear
in a Plan tree.

This was broken, because the "subplan = (SubPlan *) subplan" cast didn't
do anything, and subplan was potentially uninitialized. It meant to say
"subplan = (SubPlan *) plan".

Spotted by Daniel Gustafsson.

parser/analyze.c is bloated, moving larger chunks of GPDB-specific
functionality like this elsewhere makes it more readable. Make diffing and
merging of analyze.c with upstream easier, too.

I also ran pgindent on parse_partition.c.

parser/analyze.c is overcrowded, and since it's an upstream file, extra
code there can confuse merging (though completely new functions are less
of a problem).

Moving the installation of gp_toolkit.sql into initdb, in commit f8910c3c,
broke all the functions that are supposed to execute on all nodes, like
gp_toolkit.__gp_localid. After that change, gp_toolkit.sql was executed
in utility mode, and the gp_distribution_policy entries for those functions
were not created as a result.

To fix, change the code so that gp_distribution_policy entries are never
never created, or consulted, for EXECUTE-type external tables. They have
more fine-grained information in pg_exttable.location field anyway, so rely
on that instead. With this change, there is no difference in whether an
EXECUTE-type external table is created in utility mode or not. We would
still have similar problems if gp_toolkit contained other kinds of
external tables, but it doesn't.

This removes the isMasterOnly() function and changes all its callers to
call GpPolicyFetch() directly instead. Some places used GpPolicyFetch()
directly to check if a table is distributed, so this just makes that the
canonical way to do it. The check for system schemas that used to be in
isMasterOnly() are no longer performed, but they should've unnecessary in
the first place. System tables don't have gp_distribution_policy entries,
so they'll be treated as master-only even without that check.

Remove superflous ";" to ensure that the return value is set based
on the success of udpSignalGet(). Verified by lchang@.

This only affects OS X builds.

These were both only used by a single, static, function.

The real ones are in parse_expr.h and makefuncs.h.

gpverify functionality was planned in past to deliver online
verification of primary and mirror. It's completely dead code as never
exposed this functionality and have no plans either. It eliminates
creation of unused processes, extra directory, some shared memory and
all.

This is from a quick read through/skim of the code and comments.

This code and bug was in 1f4ad703, and it
caused an "operator XXX is not a valid ordering operator" error.

The 'sortop' field in SortClause and GroupClause needs to be an ordering
operator, i.e. the "<" operator, while we use the "=" operator to represent
grouping in other places. Need to be careful to convert between the two
in right places.

Add a few tests for this in the gp_dqa test case. This was reproducible by
the existing queries, when you coerce the planner to choose sort+group
aggregates instead of hash aggregates.

SET command is session effective, all existed idle gangs should be set for later reuse,
but for busy gangs declared by cursors, errors occur if they receive a set command. Way
to fix it is marking busy gangs to no reuse so they can be destroyed after cursors been
closed.

Heikki suggested that we backport atomic operation from PostgreSQL 9.5 to
fix this

    commit b64d92f1
    Author: Andres Freund <andres@anarazel.de>
    Date:   Thu Sep 25 23:49:05 2014 +0200

    Add a basic atomic ops API abstracting away platform/architecture details.

    Several upcoming performance/scalability improvements require atomic
    operations. This new API avoids the need to splatter compiler and
    architecture dependent code over all the locations employing atomic
    ops.

    For several of the potential usages it'd be problematic to maintain
    both, a atomics using implementation and one using spinlocks or
    similar. In all likelihood one of the implementations would not get
    tested regularly under concurrency. To avoid that scenario the new API
    provides a automatic fallback of atomic operations to spinlocks. All
    properties of atomic operations are maintained. This fallback -
    obviously - isn't as fast as just using atomic ops, but it's not bad
    either. For one of the future users the atomics ontop spinlocks
    implementation was actually slightly faster than the old purely
    spinlock using implementation. That's important because it reduces the
    fear of regressing older platforms when improving the scalability for
    new ones.

    The API, loosely modeled after the C11 atomics support, currently
    provides 'atomic flags' and 32 bit unsigned integers. If the platform
    efficiently supports atomic 64 bit unsigned integers those are also
    provided.

    To implement atomics support for a platform/architecture/compiler for
    a type of atomics 32bit compare and exchange needs to be
    implemented. If available and more efficient native support for flags,
    32 bit atomic addition, and corresponding 64 bit operations may also
    be provided. Additional useful atomic operations are implemented
    generically ontop of these.

    The implementation for various versions of gcc, msvc and sun studio have
    been tested. Additional existing stub implementations for
    * Intel icc
    * HUPX acc
    * IBM xlc
    are included but have never been tested. These will likely require
    fixes based on buildfarm and user feedback.

    As atomic operations also require barriers for some operations the
    existing barrier support has been moved into the atomics code.

    Author: Andres Freund with contributions from Oskari Saarenmaa
    Reviewed-By: Amit Kapila, Robert Haas, Heikki Linnakangas and Álvaro Herrera
    Discussion: CA+TgmoYBW+ux5-8Ja=Mcyuy8=VXAnVRHp3Kess6Pn3DMXAPAEA@mail.gmail.com,
        20131015123303.GH5300@awork2.anarazel.de,
        20131028205522.GI20248@awork2.anarazel.de

This bug was introduced in merge commit 1f4ad703, by a mishap in merging
the upstream changes to convert_IN_to_join. The constructed InInfoClause
entry was accidentally added to the list of in-clauses twice. That was
usually harmless, but if the in-clause was later pulled up from a subquery,
the code adjusts the varnos while merging the range tables of the subquery
and its parent, ran twice. In doing so, it adjusted the varno twice,
pointing it to wrong or non-existing range table entry.

Instead of creating a mock version of every backend object file, only
create mock files as needed by individual tests. Speeds up the build, and
is nicer anyway.

This inverts the logic of the <testname>_REAL_OBJS mechanism. We now link
with the real version of each object file, *except* those listed in
<testname>_MOCK_OBJS variable.

Some tests were already doing this, but it seems nicer to default to using
the real memory manager for all tests. An individual test can still opt-out
by listing the relevant files in <testname>_MOCK_OBJS. Some tests had had
to jump through hoops to mock the memory manager, which is no longer
necessary.

There are a bunch of backend files that are never mocked, but always linked
into test program as is. List those in Makefile.mock, so that every Makefile
doesn't need to list them. Makes the makefiles simpler, and you need less
boilerplate code when adding a new test program.

Not all of these backend files were listed in the _REAL_OBJS variable of
every test, but in those tests that they were not, they were also not used,
so it doesn't matter if we use the real or mock version.

This way we don't need to link the whole backend into client mock programs.
We've gotten away with it so far, but it would cause clashes if one of the
client programs contained a function or global variable with same name as
in the backend. And of course it's completely unnecessary anyway.

Seems cleaner.

They belong in headers. Otherwise, if the function's signature changes, the
compiler will not warn you.

Makes merging easier.

It's no longer needed, as Params carry a typmod now.

This was causing a segfault when compiling with -O3 on Centos 7
(gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-9)). I'm not 100% if that was
actually a compiler bug, but unaligned access would definitely be wrong
on architectures that are strict on alignment anyway.

This patch merges the PostgreSQL 9.5 implementation of SSE4.2 into GPDB.
The SSE4.2 implementation was lifted right out of PostgreSQL without
change to make merging later PostgreSQL releases easier.

Update win32 configuration to support SSE4.2 runtime checks

This change was pulled from "src/include/pg_config.h.win32" from the
commits below.

configure.in changes, determining if cpu instruction for perfomring runtime
checks are availible, and moving some of the code to port SSE4.2 came from the
following PostgreSQL commits:

commit 3dc2d62d
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date:   Tue Apr 14 17:05:03 2015 +0300

    Use Intel SSE 4.2 CRC instructions where available.

    Modern x86 and x86-64 processors with SSE 4.2 support have special
    instructions, crc32b and crc32q, for calculating CRC-32C. They greatly
    speed up CRC calculation.

    Whether the instructions can be used or not depends on the compiler and the
    target architecture. If generation of SSE 4.2 instructions is allowed for
    the target (-msse4.2 flag on gcc and clang), use them. If they are not
    allowed by default, but the compiler supports the -msse4.2 flag to enable
    them, compile just the CRC-32C function with -msse4.2 flag, and check at
    runtime whether the processor we're running on supports it. If it doesn't,
    fall back to the slicing-by-8 algorithm. (With the common defaults on
    current operating systems, the runtime-check variant is what you get in
    practice.)

    Abhijit Menon-Sen, heavily modified by me, reviewed by Andres Freund.

commit b4eb2d16
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date:   Tue Apr 14 19:56:00 2015 +0300
	On gcc and clang, the _mm_crc32_u8 and _mm_crc32_u64 intrinsics are not
	defined at all, when not building with -msse4.2. But on icc, they are.
	So we cannot assume that if those intrinsics are defined, we can always use
	them safely, we might still need the runtime check.

	To fix, check if the __SSE_4_2__ preprocessor symbol is defined. That's
	supposed to be defined only when the compiler is targeting a processor that
	has SSE 4.2 support.

	Per buildfarm members fulmar and okapi.

The current plan is to use something like pg_upgrade for future in-place
upgrades. The gpupgrade mechanism will not scale to the kind of drastic
catalog and other data directory layout changes that are coming as we
merge with later PostgreSQL releases.

Kept gpupgrademirror for now. Need to check if there's some logic that's
worth saving, for a possible pg_upgrade based solution later.

It was just syntax and catalogs, you couldn't actually do anything useful
with it. Remove it, so that we have less code to maintain, until it's time
to merge this stuff from upstream again when we merge with PostgreSQL 8.4.
It's probably easier to merge this back at that point than maintain this
backported version in the meanwhile. Less effort now, until we reach that
point, and once we get to the point in 8.4 that we merge this in, we'll
have all the preceding patches applied already, so it should merge quite
smoothly.

This makes merging and diffing with upstream easier. There were so many
GPDB-added GUCs in guc.c that "git merge" didn't handle it very well, and
you easily got merge conflicts that were error-prone to fix manually.

I kept a few GUCs in guc.c that are not present in REL8_2_0, because they
were backported from later PostgreSQL versions, rather than being
completely GPDB-specific.

Clean up the diff between guc.c and upstream, by removing unnecessary
includes, reordering a few GUCs to match upstream better, and similar
cosmetic changes.

I had to move MAX_KILOBYTES from guc.c to guc_tables.h, because guc_gp.c
needs it too. I also had to export assign_msglvl() function from guc.c, so
that it can be called from other assign_* functions from guc_gp.c. And I
had to add the code to process the ConfigureNames*_gp arrays in addition
to the upstream ones. These things increase the diff against upstream, but
not by too much, IMHO. I also copy-pasted constants like MS_PER_S and
KB_PER_MB, which seems safe as those are natural constants, and should
never change.

Now that we no longer forcibly compile strlcpy.c, and only compile and link
it into strlcpy.o into libpgport when needed, this is no longer needed.
Furthermore, it caused the linking to fail on platforms that don't need
strlcpy.o, like OS X.

Relation can potential be dropped while waiting to acquire lock.
If cannot find the relation for "if_exists" case should just emit
NOTICE and act as noop.