This GUC will be used to control the MEMO size as well as optimization
time for large IN list or large array comparison expressions.

Only the Array with less number of elements than the GUC will be
expanded and participate in constraint derivation.

Trade-off of using this GUC is loss of potential benefits from the
constraint derivation (e.g. conflict detection, partition elimination)
with shorter optimization time and less memory utilization.

This reverts commit d9edb869.
g_dataSourceCtx should not be reset in AtAbort_ExtTables, since external tables is not the only component that uses it.

A previous commit added the capability to gprecoverseg to copy all
backup files from the mirror to the primary during a full recovery,
but assumed that the backup directory would always exist and so
gprecoverseg -F would fail if it was not present.  This commit adds
a check to ensure that gprecoverseg -F will finish successfully if
there is no backup directory.

This patch updates minirepro utility to support the following functions:
1. Dump ddl and stats for multiple queries in a query file
2. Dump ddl of relation that is used in CTE
3. Dump ddl of function that is used in the query
4. Add 2 options: relation-oids and function-oids into pg_dump command line tool

Backport this patch from PostgreSQL 9.0, which replaces the tuple table
array with a linked list of individually palloc'd slots. With that, we
don't need to know the size of the array beforehand, and don't need to
count the slots. The counting was especially funky for subplans in GPDB,
and it was about to change with the upcoming PostgreSQL 8.3 merge again.
This makes it a lot simpler.

I don't plan to backport the follow-up patch to remove the ExecCountSlots
infrastructure. We'll get that later, when we merge with PostgreSQL 9.0.

commit f92e8a4b
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Sun Sep 27 20:09:58 2009 +0000

    Replace the array-style TupleTable data structure with a simple List of
    TupleTableSlot nodes.  This eliminates the need to count in advance
    how many Slots will be needed, which seems more than worth the small
    increase in the amount of palloc traffic during executor startup.

    The ExecCountSlots infrastructure is now all dead code, but I'll remove it
    in a separate commit for clarity.

    Per a comment from Robert Haas.

This reverts much of the changes vs. upstream, related to temp schema
creation. Instead of using the normal CREATE SCHEMA processing to also
create the temporary schema, let InitTempTableNameSpace() to do that
like in the upstream. But in addition to creating the the temp schema
locally, it dispatches a special CreateSchemaStmt command to the
executor nodes, which instructs the executor nodes to also call
InitTempTableNameSpace().

The regression database has grown over time, so that it's just above the
1 GB size that the regression test used as a "sanity check". I think the
new zlib regression test broke the camel's back. Bump it up to 5 GB, giving
us about 4 GB of headroom to grow.

If found inconsistent, the free tid list will be rebuilt automatically during
recovery.  During normal operation, super user may invoke the function
gp_persistent_freelist_rebuild(OID) to rebuild the free list.

A basic test case is added to verify sanity of a free tid list rebuilt using
the function.

Break long elog messages into multiple lines, remove trailing
whitespace and start elog messages with lower case.

This closes #815

This allows removing the weird pfree() of the resultTupleSlot's tuple
descriptor. What would've happened without the pfree() is that the old
slot was allocated in the first ExecAssignScanProjectionInfo() call, in
partitionMemoryContext, and then immediately destroyed when the memory
context was reset. The second call to ExecAssignScanProjectionInfo() tries
to free the slot, again, causing the segfault. But we can avoid that
by this rearrangement of the calls in a cleaner way.

In the passing, clean up the code a bit. I found having separate variables,
indexState and scanState, which point to the same struct, to be confusing.

ss_ScanTupleSlot is not an array, it's a single slot. The slot is allocated
from a bigger array, however, so this trampled over some other slot that was
allocated right after the scan slot. This has apparently been harmless, as
no-one's noticed, but it's surely wrong.

I bumped into this in the PostgreSQL 8.3 merge branch, where I had changed
the way the slots are allocated so that they're not stored in one big array
anymore. This bug led to segfaults in that case.

We had later added code that allows "DEFAULT NULL", by doing a table
rewrite. DEFAULT NULL is really the same as no default, so we might as well
do a table rewrite for that case too, and save the code needed to handle
them differently.

A function might legitimately assume that an argument's varlen datum always
has a 4-byte header, if the datatype is marked as 'plain', and crash if we
then pass it a datum with 1-byte header, because it was packed in a
memtuple. I bumped into this while working on the PostgreSQL 8.3 merge,
because the merge brought us one such function: ts_rewrite().

The one in nodeBitmapHeapScan.c is what the upstream has. The one in
execBitmapHeapScan.c was copied from it in GPDB. No need for the
duplication.

It's not clear to me why we have the execBitmapHeapScan.c file at all,
why not just use all the functions in nodeBitmapHeapScan.c. But I'll
leave investigating that for another day.

This has the effect that gpmapreduce is exempt from logging also when it
uses the extended query protocol (we only to only perform the checks in
exec_simple_query()). That makes no difference in practice, though, because
gpmapreduce doesn't actually use the extended query protocol.

The redefinitions broke the win32 build on Pulse. This was part of
3bc25384 which was backported from
upstream but left this in. This makes the win32 Pulse build green.

This isn't strictly necessary, but makes the code easier to read, IMHO.
And it seems like a very useful property that the index can only exist in
the segments, if it exists in the master.

It seems better to send in compressed form, and decompress in the receiver,
to reduce network I/O. The amount of CPU work required for the
decompression is the same whether its done in the sender or the receiver.
There was even a comment implying that, but for some reason, we didn't do
it that way.

This is in preparation for the PostgreSQL 8.3 merge: The HEAP_COMPRESSED
(and HEAP_HASEXTENDED which included it) flag was removed in PostgreSQL
8.3.

Merging is easier, when the upstream regression test files (create_index)
are as unmodified as possible, and any GPDB added tests are added to
separate files (bitmap_index). Also, the only planner vs. ORCA differences
in output were in the GPDB-added parts of this, so this allows removing
the ORCA alternative expected output file for the create_index test.

Commit dc87e717 moved DataSourceContext to TopTransactionContext, so it
doesn't need to be explicitly destroyed at end of transaction anymore. But
the pointer to it still needs to be reset.

Fixes failures in the external_table regression test.

Per report and analysis by Asim R P.

The existing run() function waits for the process to finish.  On many
occasions, e.g. transaction management tests, it is desirable to leave the
process running in background and check its status later.

Signed-off-by: NMarc Spehlmann <marc.spehlmann@gmail.com>

Signed-off-by: NZak Auerbach <zauerbach@pivotal.io>

I neglected these in previous commit.

This is a partial backport of a larger body of work which also already have
been partially backported.

Remove the GPDB-specific "breadcrumbs" mechanism from the parser. It is
made obsolete by the upstream mechanism. We lose context information from
a few errors, which is unfortunate, but seems acceptable. Upstream doesn't
have context information for those errors either.

The backport was originally done by Daniel Gustafsson, on top of the
PostgreSQL 8.3 merge. I tweaked it to apply it to master, before the
merge.

Upstream commit:

  commit b153c092
  Author: Tom Lane <tgl@sss.pgh.pa.us>
  Date:   Mon Sep 1 20:42:46 2008 +0000

    Add a bunch of new error location reports to parse-analysis error messages.
    There are still some weak spots around JOIN USING and relation alias lists,
    but most errors reported within backend/parser/ now have locations.

The function was rewritten in GPDB, and its behaviour was changed to also
return 'true' if the expression contains an Aggref of the given level.
That change in behaviour was made back in 2006, as part of a commit
containing a lot of subquery optimization changes. I could not find an
explanation for that particular change, and all the regression tests pass
without so I assume that it has become obsolete at some point over they
years.

This smoothens the way for future merges with upstream, by reducing the
diff in both code and behaviour. Also, you get a more accurate error
message in a few cases, as seen by the changes to expected output.

This brings in the intarray contrib module from 8.3 with a few
minor changes.

   * The Gin operator class is removed from the installation since
     Gin indexes are currently turned off in GPDB
   * A few compiler warnings are silenced
   * fdf2dbda which contains many
     bug-fixes is cherry-picked from upstream
   * A bug in bench.pl for printing the query plan is fixed
   * gppkg files are provided in package/

This will support fixing contrib/intarray (and probably other places)
so that they don't have to fail on arrays that contain a null bitmap
but no live null entries.

Fixes compiler warning for implicit function declaration in proc.c

Using the string literal in errmsg directly without a format string
triggers warnings in clang under -Wformat-security. Use a simple
format string containing just a reference to the string literal to
avoid warnings and possibly hiding bugs.

The tuplestore in xpath_table() is created with random access even
though it might not require it, the scaffolding for dealing with
relaxing this (commit 05bba3d1) came
the in 8.4 cycle and is yet to be merged. For now drop down to always
requesting random access awaiting the merge of the 8.4 patches.

The px_alias and int_digest structs only have two members so remove
superflous members in the initialization call.

As outlined in https://github.com/greenplum-db/gpdb/issues/685 we
have a problem with resetting GUCs in the backends when the GUC
was previously set in the per connection parameter. Explicitly set
this GUC to false since that's the intention with the RESET commands
in these cases to increase robustness of the tests.