* Derive GpCodegenUtils from CodegenUtils for GPDB specific utilities.
* Move ElogWrapper functions to GpCodegenUtils
* Implement GetOrRegisterExternalFunction

The functions GetPartitionTargetlist() and UpdateGenericExprState()
are not called from anywhere so remove.

of meaningless code.

The correct name is gp_set_proc_affinity, not gp_proc_affinity.
Spotted by Alexey Grishchenko.

in new added code.

and 42cab821, since new PANIC
issues are found related to them.

    When we execute an ALTER TABLE statement that splits default partition into a "New" and a new Default partition, we perform the following 5 steps:

     * copy the tuples located in the default partition into a temporary table,
     * drop default partition,
     * create the “New“ partition,
     * create the new DEFAULT partition, and
     * copy all tuples from the temporary table into the newly created partitions.

    The last step is executed in split_rows, where for each tuple in the temporary table,

     * we determine the target partition/table,
     * construct the slot of the target table (if is NULL), and
     * store the tuple into the target table.

    Currently, we allocate the tuple table slot of the target table into a per-tuple memory context. If the size of that memory context exceeds 50KB, then we reset it. This will cause issues, since it will free target table's slot and at the next iteration (copy the next tuple) we will try to access the attributes of a freed (and not NULL) slot. In addition, the target table slot lifespan is much longer than an individual tuple. So it is not correct to allocate the slot in a per-tuple memory context.

    To solve this issue, we allocate target's tuple table slot in PortalHeapMemory. This is the CurrentMemoryContext that is used in split_rows before we start copying tuples. PortalHeapMemory is used already for storing the tuple table slot of the temporary table and the ResultRelInfo of the target tables. PortalHeapMemory is not freed while we copy tuples. After copying all tuples to the new partitions, we drop target tables' slots.
Signed-off-by: NNikos Armenatzoglou <nikos.armenatzoglou@gmail.com>

Spotted when working on related code.

If we are unable to unlink the temporary files in the shareinput
cleanup it seems quite aggressive to insist_log() and forcibly
exit. This cleanup can be called as part of transaction abort.

When bfz_close() is called in the codepath during the abortion of a
transaction we must avoid throwing even more errors unless the
situation calls for it. For bfz_close() it's fine to lower the
ereport level to WARNING in this case. Longer term we should move
this, and other, codepaths away from calling unlink() directly and
instead use the API provided but this closes a current issue in
ICG so better to close this immediately and refactor all callsites
when having a clean ICG.

The LOG_GANG_DEBUG statements that include members in the Gang struct
should only run after we've validated that the Gang struct pointers
aren't NULL to avoid segfaulting.

Found this README while reading some code and rather than fixing
the incorrect path specification it seemed equally useful to just
remove it since it carries very little information.

When create gang failed and all segment DB are alive,
we could retry when any of the following conditions is met:
1) This is the writer gang.
2) This is the first reader gang and the writer gang is healthy.
3) All failed connections are due to segment recovery.

Signed-off-by: NShreedhar Hardikar <shardikar@gmail.com>

This closes #836
Signed-off-by: NMarc Spehlmann <cramja@gmail.com>

reorder header file

This closes #858

Currently gp_connections_per_thread=0 means using main thread to
do dispatch instead of creating new threads. It's not working if
segments report error before sending back any data.
For example:
create table foo(id int);
insert into foo values(0);
set gp_connections_per_thread=0;
select 100/id from foo;

We disable it for now and will reenable it when we have the new
implementation of non-threaded dispatcher.

We had backported similar changes to the other pg_*_is_visible()
functions earlier, so for consistency, do the same for the new functions
we got from the 8.3 merge.

The related upstream commit was:

commit 66bb74db
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Mon Dec 15 18:09:41 2008 +0000

    Arrange for the pg_foo_is_visible and has_foo_privilege families of functions
    to return NULL, instead of erroring out, if the target object is specified by
    OID and we can't find that OID in the catalogs.  Since these functions operate
    internally on SnapshotNow rules, there is a race condition when using them
    in user queries: the query's MVCC snapshot might "see" a catalog row that's
    already committed dead, leading to a failure when the inquiry function is
    applied.  Returning NULL should generally provide more convenient behavior.
    This issue has been complained of before, and in particular we are now seeing
    it in the regression tests due to another recent patch.

It doesn't seem too useful, to hae a DEBUG1 of tuple counts. I doubt
anyone has taken advantage of that in years. Removing it allows us
to refactor the code inside GetPlannedStmtLogLevel() back into
GetCommandLogLevel(), like it is in the upstream.

There are no callers to it outside the file, so why not. Reduces the
diff vs. upstream.

This seems like a completely unnecessary change. Reduce the diff vs.
upstream.

Not sure what this was used for or when, but it's dead now.

Removed maxlen as a maximum size for the custom format supporting fixed
format descriptions. Allows for the creation of tables having up to
MaxHeapAttributeNumber of columns.