Commit 38686122 changed the function to not give a WARNING, but neglected
the comment that says it does.

Libraries like libssl libkrb5 are not included in the compile flags, so add those
missing libraries to make codegen unittest pass.

A bunch of functions and classes that are not used anywhere.

Ignore AccessMethodProcedureRelationId as pg_amproc do not need
OID synchronized between master and segments.

The NUM_EXTRA_OIDS_FOR_BITMAP macro was only used for generating a
set of extra relfilenodes for when running vacuuming a bitmap index.
With the new relfilenode handling in 88f0623e it's no loger required.

To test, backport test case for CREATE CAST from PostgreSQL 8.4. We don't
apparently have any coverage for it previously. The upstream commit for the
test case was:

commit a1d2e165
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date:   Fri Oct 31 09:17:17 2008 +0000

    Add test case for CREATE CAST.

Reported by Yandong Yao

There was a race condition in the way relfilenodes were chosen, because
QE nodes chose relfilenodes for existing relations, e.g. at REINDEX or
TRUNCATE, independently of the master, while for newly created tables,
the relfilenode was chosen by the master. To fix:

1. If the OID of a newly-created table is already in use as relfilenode
   of a different table in a QE segment, use a different relfilenode.
   (This shouldn't happen in the dispatcher, for the same reasons it
   cannot happen in a single-server PostgreSQL instance)

2. Use a small cache of values recently used for a relfilenode, to close
   a race condition between checking if a relfilenode is in use, and
   actually creating the file

Signed-off-by: NNikos Armenatzoglou <nikos.armenatzoglou@gmail.com>

* Making expression tree mutation unconditional

We previously did not consider that we need to mutate an expression tree
only if there is a pseudo column. This introduces an executor crash in
non-assert build as executor does not know how to interpret a pseudo
column. Moreover, in assert build we fail an assert.

The conditional we are removing  was introduced to optimize performance
by commit a36436ea, but a quick performance
run shows that performance is not noticeably affected by removing the
optimization. [#131785597]
Signed-off-by: NFoyzur Rahman <foyzur@gmail.com>

* Adding PR comments.

Having an "extern" declaration directly in a C file is a bad habit, because
that can fail in surprising ways if the datatype of the variable is changed.
In thise case, we don't really need to check the variable at all, because
these functions are only used from ORCA.

Now that we capture and dispatch OIDs separately, we can revert these
changes vs. upstream.

I wasn't 100% sure if the change in bmbulkdelete() was OK. We no longer
update the relNode in the relcache entry. However, running this in a
debugger shows that reindex_index() updates the relcache entry itself,
so setting it in bmbulkdelete should not be necessary. Also, the
regression tests are happy with this.

No functional changes. Operator look up code had been refactored into
separate fetch_op_tup() function in GPDB, but that was rather pointless.
Revert it the way it's in the upstream, to reduce our diff footprint.

The upstream doesn't have it, and it's an odd one out, when none of the
other syscaches have such macros. This reduces our diff vs. upstream, which
makes diffing and merging easier.

We have no plans to add columsn to AO metadata tables using ALTER TABLE.
Even if we did, the penalty of a single syscache lookup hardly matters.

We don't do EXEC_BACKEND builds at the moment, but if we did, this would
likely cause compiler or Coverity warnings. Or a crash at runtime, if a
locale had a really long name.

Transactional stats for heap_delete must be updated only if in transaction,
which should always be the case. Except the issue was encountered now when we
started calling heap_delete for PT tables to free tuples instead of older
mechanism. During recovery based on object state if transaction was aborted the
tuple in PT needs to be deleted and was failing in this function as
TopTransactionContext is not allocated. Hence, added the protection that only if
nesting level if greater than 0 which will be the case if we are in transaction
collect stats else ignore the same. Which helps to fix the problem.

Commit f9016da2 removed the definition of the relid variable, remove
the assertion on it as well.

Instead of carrying a "new OID" field in all the structs that represent
CREATE statements, introduce a generic mechanism for capturing the OIDs
of all created objects, dispatching them to the QEs, and using those same
OIDs when the corresponding objects are created in the QEs. This allows
removing a lot of scattered changes in DDL command handling, that was
previously needed to ensure that objects are assigned the same OIDs in
all the nodes.

This also provides the groundwork for pg_upgrade to dictate the OIDs to use
for upgraded objects. The upstream has mechanisms for pg_upgrade to dictate
the OIDs for a few objects (relations and types, at least), but in GPDB,
we need to preserve the OIDs of almost all object types.

Asserting that an assignment isn't zero is a valid use of Assert(),
but these instances look more like accidental assignments due to a
missing '='. getgpsegmentCount() is already internally asserting
that the count is > 0 so we would never reach here in case it was.

The code that we generate for slot_getattr is not correct.
In particular, to check if a tuple is virtual, we have to implement the code below:
if (TupHasVirtualTuple(slot) && slot->PRIVATE_tts_nvalid >= attnum)

In the codegened slot_getattr, we had not implemented the
second condition, i.e., slot->PRIVATE_tts_nvalid >= attnum.

In this commit, we generate code for the second condition.

Signed-off-by: NKenan Yao <kyao@pivotal.io>

So far we were assuming that the content of `llvm_isNull_ptr` variable, which is passed as
input to expression evaluation, is always `false`. Consequently, when the result of the
expression is not null, we avoid setting `llvm_isNull_ptr` to `false`.

However, this assumption is not correct since in codegen we do not use a temporary `fcinfo`
struct (for perfromance reasons), which initializes `fcinfo->isnull` to `false`.
Instead, we pass a pointer to the isnull variable of the caller directly (which might not
have been inititialized). For example, in `GenerateAdvanceAggregates` we pass a pointer
to `transValueIsNull`.

In this commit, we explicitly set `llvm_isNull_ptr` to `false` when the result is not null.
This will cover all cases that the input is not initialized to `false`.
Signed-off-by: NKarthikeyan Jambu Rajaraman <karthi.jrk@gmail.com>

Codegened advance_aggregares did not support null attributes. With this
patch, we enhance it with checks for strict functions and create the
proper arguments' nullity checks accordingly.

Authors: Nikos Armenatzoglou and Jimmy Yih

This avoids a lot of overhead for short read-only queries. We still don't
do lazy assignment for most transactions, like PostgreSQL 8.3 does, but
this is a step in the right direction.

Segments that are still in an old format are treated as read-only. All new
data go to new segments, in new format. This allows us to eventually get
rid of the old format completely.

This is hypothetical until we have pg_upgrade working for GPDB 4.3 -> 5.0
upgrade, as you can't have old-format tables or segments at all in a
cluster that's initialized with 5.0. Stay tuned for pg_upgrade, but this
is preparatory work for that.

This meant moving the version field from pg_appendonly to the
pg_aoseg_<oid> table (or pg_aocsseg_<oid>, for AOCS). We can still read
and write both formats, but new segments will always be created in the new
format (except if you set the test_appendonly_version_default GUC).

Remove unused fields from past version control systems and ensure
that all filenames in the comments match the actual name of the file.
Also fix some spelling and references.

pgstat_write_statsfile() failed to write the resource queue statistics
to the stat file which in turn makes the pg_stat_resqueues view empty.

Patch by Github user LJoNe with testcase added by me

gporca has a set of banned API calls which needs to be allowed with the
ALLOW_xxx macro in order for gpopt to compile. But it should be the
library caller(GPDB/Orca)'s resposibility to take care of the function call.

see discussions on greenplum-db/gpdb#1136
and https://groups.google.com/a/greenplum.org/forum/#!topic/gpdb-dev/Mcw6JPav6h4

* Adding support for interrupt processing before reserving more vmem.

* Process pending interrupts before reserving VMEM.

* Adding guc to control vmem tracker checking for interrupts before reserving more vmem.

In many places where we had used a mixture of spaces and tabs for
indentation, new versions of gcc complained about misleading indentation,
because gcc doesn't know we're using tab width of 4. To fix, make the
indentation consistent in all the places where gcc gave a warning. Would
be nice to fix it all around, but that's a lot of work, so let's do it
in a piecemeal fashion whenever we run into issues or need to modify a
piece of code anyway.

For some files, especially the GPDB-specific ones, I ran pgindent over
the whole file. I used the pgindent from PostgreSQL master, which is
slightly different from what was used back 8.3 days, but that's what I had
easily available, and that's what we're heading to in the future anyway.
In some cases, I didn't commit the pgindented result if there were
funnily formatted code or comments that would need special treatment.

For other places, I fixed the indentation locally, just enough to make the
warnings go away.

I also did a tiny bit of other trivial cleanup, that I happened to spot
while working on this, although I tried to refrain from anything more
extensive.

- In ORCA, due to the way exception handled previously we do warning first
and then later print error referring that message. In this commit, we
enhanced the exception handling so we just print a single error message.
- Also, we removed 'PQO unable to generate a plan' or 'Aborting PQO plan
generation' message and make the error message as close as the planner.
- Updated error message with filename and line number from where the exception
is raised.

Environment variables of QD should not be included in the startup packet when making connections to segments.
Add ICG test case to guarantee the QD env variable should not effect GUCs on segments
Signed-off-by: NPengzhou Tang <ptang@pivotal.io>

constant format strings, so that the compiler can more easily check the
formats for correctness.

 Conflicts:
	src/backend/postmaster/postmaster.c
	src/interfaces/ecpg/pgtypeslib/dt_common.c

Commit ff3474e2 which removed the gp_partition_* catalog functions
left some auxiliary code behind which is now unused. Remove the now
dead functions and while in there, put back the filename in the file
headercomment to match other files.