Revert the code to open/read/write regular files, to the way it's in the
upstream.

* Revert almost all the changes in smgr.c / md.c, to not go through
  the Mirrored* APIs.

* Remove mmxlog stuff. Use upstream "pending relation deletion" code
  instead.

* Get rid of multiple startup passes. Now it's just a single pass like
  in the upstream.

* Revert the way database drop/create are handled to the way it is in
  upstream. Doesn't use PT anymore, but accesses file system directly,
  and WAL-logs a single CREATE/DROP DATABASE WAL record.

* Get rid of MirroredLock

* Remove a few tests that were specific to persistent tables.

* Plus a lot of little removals and reverts to upstream code.

This seems to have been similar to the fault injector code we have, but
not used by anything as far as I can see.

Commit 3fe43b8a introduced a lock upgrade in the plan revalidation
for UDFs. This makes the lock acquire in RevalidateCachedPlanWithParams()
match CdbTryOpenRelation() closer in order to avoid distributed deadlock
for UPDATE/DELETE DMLs. It does however also upgrade the lock for INSERT
which is overly aggressive. Fix by only upgrading the lock for the two
specified DML commands. Also includes an isolationtest test that cause
distributed deadlock without this patch.

This solves reported cases of deadlock introduced around INSERTs in UDFs.

This is backport from PostgreSQL 9.4. It brings back functionality that we
lost with the ripout & replace of the window function implementation.

I left out all the code and tests related to COLLATE, because we don't have
that feature. Will need to put that back when we merge collation support, in
9.1.

commit 8d65da1f
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Mon Dec 23 16:11:35 2013 -0500

    Support ordered-set (WITHIN GROUP) aggregates.

    This patch introduces generic support for ordered-set and hypothetical-set
    aggregate functions, as well as implementations of the instances defined in
    SQL:2008 (percentile_cont(), percentile_disc(), rank(), dense_rank(),
    percent_rank(), cume_dist()).  We also added mode() though it is not in the
    spec, as well as versions of percentile_cont() and percentile_disc() that
    can compute multiple percentile values in one pass over the data.

    Unlike the original submission, this patch puts full control of the sorting
    process in the hands of the aggregate's support functions.  To allow the
    support functions to find out how they're supposed to sort, a new API
    function AggGetAggref() is added to nodeAgg.c.  This allows retrieval of
    the aggregate call's Aggref node, which may have other uses beyond the
    immediate need.  There is also support for ordered-set aggregates to
    install cleanup callback functions, so that they can be sure that
    infrastructure such as tuplesort objects gets cleaned up.

    In passing, make some fixes in the recently-added support for variadic
    aggregates, and make some editorial adjustments in the recent FILTER
    additions for aggregates.  Also, simplify use of IsBinaryCoercible() by
    allowing it to succeed whenever the target type is ANY or ANYELEMENT.
    It was inconsistent that it dealt with other polymorphic target types
    but not these.

    Atri Sharma and Andrew Gierth; reviewed by Pavel Stehule and Vik Fearing,
    and rather heavily editorialized upon by Tom Lane

Also includes this fixup:

commit cf63c641
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Mon Dec 23 20:24:07 2013 -0500

    Fix portability issue in ordered-set patch.

    Overly compact coding in makeOrderedSetArgs() led to a platform dependency:
    if the compiler chose to execute the subexpressions in the wrong order,
    list_length() might get applied to an already-modified List, giving a
    value we didn't want.  Per buildfarm.

This adds some limitations, and removes some functionality that tte old
implementation had. These limitations will be lifted, and missing
functionality will be added back, in subsequent commits:

* You can no longer have variables in start/end offsets

* RANGE is not implemented (except for UNBOUNDED)

* If you have multiple window functions that require a different sort
  ordering, the planner is not smart about placing them in a way that
  minimizes the number of sorts.

This also lifts some limitations that the GPDB implementation had:

* LEAD/LAG offset can now be negative. In the qp_olap_windowerr, a lot of
  queries that used to throw an "ROWS parameter cannot be negative" error
  are now passing. That error was an artifact of the eay LEAD/LAG were
  implemented. Those queries contain window function calls like "LEAD(col1,
  col2 - col3)", and sometimes with suitable values in col2 and col3, the
  second argument went negative. That caused the error. implementation of
  LEAD/LAG is OK with a negative argument.

* Aggregate functions with no prelimfn or invprelimfn are now supported as
  window functions

* Window functions, e.g. rank(), no longer require an ORDER BY. (The output
  will vary from one invocation to another, though, because the order is
  then not well defined. This is more annoying on GPDB than on PostgreSQL,
  because in GDPB the row order tends to vary because the rows are spread
  out across the cluster and will arrive in the master in unpredictable
  order)

* NTILE doesn't require the argument expression to be in PARTITION BY

* A window function's arguments may contain references to an outer query.

This changes the OIDs of the built-in window functions to match upstream.
Unfortunately, the OIDs had been hard-coded in ORCA, so to work around that
until those hard-coded values are fixed in ORCA, the ORCA translator code
contains a hack to map the old OID to the new ones.

  commit e5536e77
  Author: Tom Lane <tgl@sss.pgh.pa.us>
  Date:   Mon Aug 25 22:42:34 2008 +0000

      Move exprType(), exprTypmod(), expression_tree_walker(), and related routines
      into nodes/nodeFuncs, so as to reduce wanton cross-subsystem #includes inside
      the backend.  There's probably more that should be done along this line,
      but this is a start anyway
Signed-off-by: NShreedhar Hardikar <shardikar@pivotal.io>

We already had a hack for the EXECUTE ON ALL SEGMENTS case, by setting
prodataaccess='s'. This exposes the functionality to users via DDL, and adds
support for the EXECUTE ON MASTER case.

There was discussion on gpdb-dev about also supporting ON MASTER AND ALL
SEGMENTS, but that is not implemented yet. There is no handy "locus" in the
planner to represent that. There was also discussion about making a
gp_segment_id column implicitly available for functions, but that is also
not implemented yet.

The old behavior was that a function that if a function was marked as
IMMUTABLE, it could be executed anywhere. Otherwise it was always executed
on the master. For backwards-compatibility, this keeps that behavior for
EXECUTE ON ANY (the default), so even if a function is marked as EXECUTE ON
ANY, it will always be executed on the master unless it's IMMUTABLE.

There is no support for these new options in ORCA. Using any ON MASTER or
ON ALL SEGMENTS functions in a query cause ORCA to fall back. This is the
same as with the prodataaccess='s' hack that this replaces, but now that it
is more user-visible, it would be nice to teach ORCA about it.

The new options are only supported for set-returning functions, because for
a regular function marked as EXECUTE ON ALL SEGMENTS, it's not clear how
the results should be combined. ON MASTER would probably be doable, but
there's no need for that right now, so punt.

Another restriction is that a function with ON ALL SEGMENTS or ON MASTER can
only be used in the FROM clause, or in the target list of a simple SELECT
with no FROM clause. So "SELECT func()" is accepted, but "SELECT func() FROM
foo" is not. "SELECT * FROM func(), foo" works, however. EXECUTE ON ANY
functions, which is the default, work the same as before.

If a prepared statement, or a cached plan for an SPI query e.g. from a
PL/pgSQL function, contains stable functions, the stable functions were
incorrectly evaluated only once at plan time, instead of on every execution
of the plan. This happened to not be a problem in queries that contain any
parameters, because in GPDB, they are re-planned on every invocation
anyway, but non-parameter queries were broken.

In the planner, before this commit, when simplifying expressions, we set
the transform_stable_funcs flag to true for every query, and evaluated all
stable functions at planning time. Change it to false, and also rename it
back to 'estimate', as it's called in the upstream. That flag was changed
back in 2010, in order to allow partition pruning to work with qual
containing stable functions, like TO_DATE. I think back then, we always
re-planned every query, so that was OK, but we do cache plans now.

To avoid regressing to worse plans, change eval_const_expressions() so that
it still does evaluate stable functions, even when the 'estimate' flag is
off. But when it does so, mark the plan as "one-off", meaning that it must
be re-planned on every execution. That gives the old, intended, behavior,
that such plans are indeed re-planned, but it still allows plans that don't
use stable functions to be cached.

This seems to fix github issue #2661. Looking at the direct dispatch code
in apply_motion(), I suspect there are more issues like this lurking there.
There's a call to planner_make_plan_constant(), modifying the target list
in place, and that happens during planning. But this at least fixes the
non-direct dispatch cases, and is a necessary step for fixing any remaining
issues.

For some reason, the query now gets planned *twice* for every invocation.
That's not ideal, but it was an existing issue for prepared statements with
parameters, already. So let's deal with that separately.

This bumps the copyright years to the appropriate years after not
having been updated for some time.  Also reformats existing code
headers to match the upstream style to ensure consistency.

Hopefully avoids a couple of merge conflicts in the future.

Fix Relcache Translator to send CoercePath info

Currently ORCA crashes while executing following query:
```
CREATE TABLE FOO(a integer NOT NULL, b double precision[]);
SELECT b FROM foo
UNION ALL
SELECT ARRAY[90, 90] as Cont_features;
```

In the query, we are appending an integer array (ARRAY[90, 90]) to a double
precision array (foo.b) and hence we need to apply a cast on ARRAY[90, 90] to
generate ARRAY[90, 90]::double precision[].
In gpdb5 there is not direct function available that can cast array of any type
to array of any other type.
So in relcache to dxl translator we look into the array elements and get their type
and try to find a cast function for them.  For this query, source type is 23 i.e.
integer and destination type is 701 i.e. double precision and we try to find if
we have a conversion function for 23 -> 701. Since that is available we send
that function to ORCA as follows:
```
<dxl:MDCast Mdid="3.1007.1.0;1022.1.0"
Name="float8" BinaryCoercible="false" SourceTypeId="0.1007.1.0"
DestinationTypeId="0.1022.1.0" CastFuncId="0.316.1.0"/>
```
Here we are misinforming ORCA by specifying that function with id 316 is available
to convert type 1007 i.e. integer array to 1022 i.e. double precision array.
However Function id 316 is simple int4 to float8 conversion function and it CAN NOT
convert an array of int4 to array of double precision. ORCA generates a plan
using this function but executor crashes while executing this function because
this function can not handle arrays.

This commit fixes this issue by passing a ArrayCoercePath info to ORCA.
In Relcache Translator, The appropriate cast function is retrieved in `gpdb::FCastFunc()`
which relies on `find_coercion_pathway()` to provide the cast function oid given the src
and dest types.

`find_coercion_pathway()` does not just determines the cast function to be used but
also determines the coercion path; however we ignored the coercision path
and generate a simple Cast Metadata Object.

With this commit, we now pass the pathtype to relcache translator and
generate ArrayCoerceCast Metadata object depending on the coercion path.

In ORCA, when the dxl is translated to expression, we check the path type along with
the cast function and generate `CScalarArrayCoerceExpr` if the path type is
array coerce path; otherwise we generate simple `CScalaraCast`.

Please check the corresponding ORCA PR.

Bump ORCA version to 2.40
Signed-off-by: NBhuvnesh Chaudhary <bchaudhary@pivotal.io>

Instead of meticulously recording the OIDs of each object in the pg_dump
output, dump and load all OIDs as a separate steps in pg_upgrade.

We now only preserve OIDs of types, relations and schemas from the old
cluster. Other objects are assigned new OIDs as part of the restore.
To ensure the OIDs are consistent between the QD and QEs, we dump the
(new) OIDs of all objects to a file, after upgrading the QD node, and use
those OIDs when restoring the QE nodes. We were already using a similar
mechanism for new array types, but we now do that for all objects.

ExclusiveLock should be acquired in place of RowExclusiveLock for DMLs on user
tables.  If RowExclusiveLock is acquired, we may have a local deadlock on QD
when concurrent UPDATE statements are executed from within UDFs.

The problem is described in more detail here:
https://groups.google.com/a/greenplum.org/d/msg/gpdb-dev/PC0Z_zw-YaY/tsCmPdADBQAJ

This brought in postgres/postgres@44d5be0 pretty much wholesale, except:

1. We leave `WITH RECURSIVE` for a later commit. The code is brought in,
    but kept dormant by us bailing early at the parser whenever there is
    a recursive CTE.
2. We use `ShareInputScan` in the stead of `CteScan`. ShareInputScan is
    basically the parallel-capable `CteScan`. (See `set_cte_pathlist`
    and `create_ctescan_plan`)
3. Consequently we do not put the sub-plan for the CTE in a
    pseudo-initplan: it is directly present in the main plan tree
    instead, hence we disable `SS_process_ctes` inside
    `subquery_planner`
4. Another corollary is that all new operators (`CteScan`,
    `RecursiveUnion`, and `WorkTableScan`) are dead code right now. But
    they will come to live once we bring in parallel implementation of
    `WITH RECURSIVE`

In general this commit reduces the divergence between Greenplum and
upstream.

User visible changes:
The merge in parser enables a corner case previously treated as error:
you can now specify fewer columns in your `WITH` clause than the actual
projected columns in the body subquery of the `WITH`.

Original commit message:

> Implement SQL-standard WITH clauses, including WITH RECURSIVE.
>
> There are some unimplemented aspects: recursive queries must use UNION ALL
> (should allow UNION too), and we don't have SEARCH or CYCLE clauses.
> These might or might not get done for 8.4, but even without them it's a
> pretty useful feature.
>
> There are also a couple of small loose ends and definitional quibbles,
> which I'll send a memo about to pgsql-hackers shortly.  But let's land
> the patch now so we can get on with other development.
>
> Yoshiyuki Asaba, with lots of help from Tatsuo Ishii and Tom Lane
>

(cherry picked from commit 44d5be0e)

We were not storing sourceTag in CachedPlanSource, so if a cached plan
is used later, that field is broken, and would break resource queue
concurrency limit functionality for example.

Reported by issue #2308 when using JDBC/ODBC

QD used to send a transient types table to QEs, then QE would remap the
tuples with this table before sending them to QD. However in complex
queries QD can't discover all the transient types so tuples can't be
correctly remapped on QEs. One example is like below:

    SELECT q FROM (SELECT MAX(f1) FROM int4_tbl
                   GROUP BY f1 ORDER BY f1) q;
    ERROR:  record type has not been registered

To fix this issue we changed the underlying logic: instead of sending
the possibly incomplete transient types table from QD to QEs, we now
send the tables from motion senders to motion receivers and do the remap
on receivers. Receivers maintain a remap table for each motion so tuples
from different senders can be remapped accordingly. In such way, queries
contain multi-slices can also handle transient record type correctly
between two QEs.

The remap logic is derived from the executor/tqueue.c in upstream
postgres. There is support for composite/record types and arrays as well
as range types, however as range types are not yet supported in GPDB so
the logic is put under a conditional compilation macro, in theory it
shall be automatically enabled when range types are supported in GPDB.

One side effect for this approach is that on receivers a performance
down is introduced as the remap requires recursive checks on each tuple
of record types. However optimization is made to make this side effect
minimum on non-record types.

Old logic that building transient types table on QD and sending them to
QEs are retired.
Signed-off-by: NGang Xiong <gxiong@pivotal.io>
Signed-off-by: NNing Yu <nyu@pivotal.io>

The master allocates an OID and provides it to segments during
dispatch. The segments then check if they can use this OID as its
relfilenode. If a segment cannot use the preassigned OID as the
relation's relfilenode, it will generate a new relfilenode value via
nextOid counter. This can result in a race condition between the
generation of the new OID and the segment file being created on disk
after being added to persistent tables. To combat this race condition,
we have a small OID cache... but we have found in testing that it was
not enough to prevent the issue.

To fully solve the issue, we decouple OID and relfilenode on both QD and QE
segments by introducing a nextRelfilenode counter which is similar to
the nextOid counter. The QD segment will generate the OIDs and its own
relfilenodes. The QE segments only use the preassigned OIDs from the QD
dispatch and generate a relfilenode value from their own nextRelfilenode
counter.

Current sequence generation is always done on QD sequence server, and
assumes the OID is always same as relfilenode when handling sequence client
requests from QE segments. It is hard to change this assumption so we have a
special OID/relfilenode sync for sequence relations for GP_ROLE_DISPATCH and
GP_ROLE_UTILITY.

Reference gpdb-dev thread:
https://groups.google.com/a/greenplum.org/forum/#!topic/gpdb-dev/lv6Sb4I6iSISigned-off-by: NXin Zhang <xzhang@pivotal.io>

This reverts commit ab4398dd.
[#142986717]

QD used to send a transient types table to QEs, then QE would remap the
tuples with this table before sending them to QD. However in complex
queries QD can't discover all the transient types so tuples can't be
correctly remapped on QEs. One example is like below:

    SELECT q FROM (SELECT MAX(f1) FROM int4_tbl
                   GROUP BY f1 ORDER BY f1) q;
    ERROR:  record type has not been registered

To fix this issue we changed the underlying logic: instead of sending
the possibly incomplete transient types table from QD to QEs, we now
send the tables from motion senders to motion receivers and do the remap
on receivers. Receivers maintain a remap table for each motion so tuples
from different senders can be remapped accordingly. In such way, queries
contain multi-slices can also handle transient record type correctly
between two QEs.

The remap logic is derived from the executor/tqueue.c in upstream
postgres. There is support for composite/record types and arrays as well
as range types, however as range types are not yet supported in GPDB so
the logic is put under a conditional compilation macro, in theory it
shall be automatically enabled when range types are supported in GPDB.

One side effect for this approach is that on receivers a performance
down is introduced as the remap requires recursive checks on each tuple
of record types. However optimization is made to make this side effect
minimum on non-record types.

Old logic that building transient types table on QD and sending them to
QEs are retired.
Signed-off-by: NGang Xiong <gxiong@pivotal.io>
Signed-off-by: NNing Yu <nyu@pivotal.io>

The need for heap access methods before xlog replay is removed by commit
e2d6aa1481f6cdbd846d4b17b68eb4387dae9211. This commit simply moves the
relcache initialization to pass4, where it is really needed.

Do not bother to remove relcache init file at the end of crash recovery pass2.

Error out if relation cache initialized at wrong time.

Debug_gp_relation_node_fetch_wait_for_debugging was added to assist
debugging an issue in the RelationFetchGpRelationNodeForXLog recursion
guard. The bug was not reproduced but the GUC was left in when the
ticket was closed so remove. If we need to debug this in the future
we should add something back then.

The current dbInfoRel hash table key only contains the relfilenode
oid. However, relfilenode oids can be duplicated over different
tablespaces which can cause dropdb (and possibly persistent rebuild)
to fail. This commit adds the tablespace oid as part of the dbInfoRel
hash table key for more uniqueness.

One thing to note is that a constructed tablespace/relfilenode key is
compared with other keys using memcmp. Supposedly... this should be
fine since the struct just contains two OID variables and the keys are
always palloc0'd. The alignment should be fine during comparison.

Currently we see FTS failure in the CI pipeline due to the filerep resync
manager and workers are still in the recovery mode while relcache got
initialized.

This reverts commit f8f6587e and
0e9d10d2.

The need for heap access methods before xlog replay is removed by commit
e2d6aa1481f6cdbd846d4b17b68eb4387dae9211.  This commit simply moves the
relcache initialization to pass4, where it is really needed.

Do not bother to remove relcache init file at the end of crash recovery pass2.

Error out if relation cache initialized at wrong time.

None of the source files that #included gp_atomic.h actually needed the
declarations from gp_atomic.h. They actually needed the definitions from
port/atomics.h, which gp-atomic.h in turn #included.

Relfilenode is only unique within a tablespace. Across tablespaces same
relfilenode may be allocated within a database. Currently, gp_relation_node only
stores relfilenode and segment_num and has unique index using only those fields
without tablespace. So, it breaks for situations where same relfilenode gets
allocated to table within database.

- continue to merge the remaining part of extension framework,
include alter extension, extension view, extension upgrade,
psql support.
- Make plpgsql available as an extension.
- Support dump for extension.
- Use new oid dispatch method to for extension oid

commit d9572c4e
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Tue Feb 8 16:08:41 2011 -0500

    Core support for "extensions", which are packages of SQL objects.

    This patch adds the server infrastructure to support extensions.
    There is still one significant loose end, namely how to make it play nice
    with pg_upgrade, so I am not yet committing the changes that would make
    all the contrib modules depend on this feature.

    In passing, fix a disturbingly large amount of breakage in
    AlterObjectNamespace() and callers.

    Dimitri Fontaine, reviewed by Anssi Kääriäinen,
    Itagaki Takahiro, Tom Lane, and numerous others

commit 5bc178b8
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Wed Feb 9 11:55:32 2011 -0500

    Implement "ALTER EXTENSION ADD object".

    This is an essential component of making the extension feature usable;
    first because it's needed in the process of converting an existing
    installation containing "loose" objects of an old contrib module into
    the extension-based world, and second because we'll have to use it
    in pg_dump --binary-upgrade, as per recent discussion.

    Loosely based on part of Dimitri Fontaine's ALTER EXTENSION UPGRADE
    patch.

commit 01467d3e
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Thu Feb 10 17:36:44 2011 -0500

    Extend "ALTER EXTENSION ADD object" to permit "DROP object" as well.

    Per discussion, this is something we should have sooner rather than later,
    and it doesn't take much additional code to support it.

commit 12147499
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   Fri Feb 11 21:25:20 2011 -0500

    Add support for multiple versions of an extension and ALTER EXTENSION UPDATE.

    This follows recent discussions, so it's quite a bit different from
    Dimitri's original.  There will probably be more changes once we get a bit
    of experience with it, but let's get it in and start playing with it.

    This is still just core code.  I'll start converting contrib modules
    shortly.

    Dimitri Fontaine and Tom Lane

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

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.

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.

Relcache init file was failing to load because of duplicate occurrence of
OpclassOidIndexId in the nailed indexes list.  Consequently, relcache was
always built from scratch upon every child process startup.  Also added
OperatorOidIndex from upstream to the nailed index list, to match upstream
(8.3), as pointed out by Heikki.
Signed-off-by: NAsim R P <apraveen@pivotal.io>

DDL statements, such as reindex, change relfilenode of a relcache
entry.  This triggers invalidation but we were keeping the old
persistent TID upon invalidation.  Change this so that persistent TID
is also reset upon invalidation, if relfilenode of the relcache entry
has changed.

We have observed that the persistent TID and serial number associated with a
relfilenode in a relation descriptor may be updated to a new value before
relfilenode is updated.  If an XLog record is written with such a relation
descriptor, then the XLog record fails to apply during recovery.

This commit adds a check to validate sanity of persistent information in a
relation descriptor by fetching persistent information using relfilenode from
gp_relation_node.

The validation is controlled by a new GUC, gp_validate_pt_info_relcache.

Refactor code to use common routine to fetch PT info for xlogging. Check can
be easliy added at this common place to validate persistent info is
available. Plus still add check during recovery for persistentTID zero. As
with postgres upstream merges possible the function to populate persistent info is
not called at all, so this check will not hit during xlog record construction
but atleast gives clear clue during recovery.

The previous commits have removed all usage of CaQL. It's no longer
needed.

It was used for DELETEs, and SELECT COUNT(*). Replace with the usual
syscache lookups, systable scans, and simple_heap_update/delete calls,
like these things are done in the upstream.