Currently, during insert to AO/CO tables check is performed to validate
file-offset (EOF) found from pg_aoseg which would be used to start writing
the data to file. The offset to start writing needs to be greater than
currently marked EOF in persistent table. The validation is currently
performed for all other scenarios except EOF=0, so this commit is modifing to
enable it for EOF-0 case as well. As it was seen in field for yet to be known
reasons maybe indexing issues on pg_aoseg table, that incorrect EOF=0 was
fetched from aoseg and valid data was over-written. So, this protection will
prevent data-loss scenarios.

This commit adds gpperfmon/logs/ to the exclusion list and also corrects
gp_dumps/ to db_dumps/ which gpinitstandby sends as args to pg_basebackup to
initialize the standby master. This should speed up gpinitstandby if a user
uses gpperfmon/gpcc or gpcrondump.

Authors: Amil Khanzada and Jimmy Yih

gp_dbid gp_num_contents_in_cluster gp_contentid
-b is being used upstream for binary upgrade mode.
The rest because of future conflict issues. The long options will always work

Also updated gp_optimizer expected output and ignore line number
difference for functions.c

We don't use CaQL here anymore. Fix to match upstream.

We don't use CaQL here anymore.

We just got rid of the last users of them.

To reduce our diff vs upstream, to make diffing and merging easier.

It's a plain heap tuple in the usptream. This reduces the diff vs.
upstream.

Use a regular syscache lookup like in the upstream, and get rid of the
now-unused get_func_namespace function.

While it might make sense to extract this duplicated code to a function,
let's rather avoid the difference from upstream.

FTS doesn't actually seem to use the superuser's username for anything.
That allowed removing probeUser and retrieveUserAndDb(). All the remaining
calls to FtsFindSuperuser() were from cdbresynchronizechangetracking.c,
but all of those callers just discarded the return value.
FtsFindSuperuser() doesn't throw any errors, either, so it didn't serve
any error-checking purpose either. Remove it all.

Not that it matters from a performance point of view, but surely it was
not intended.

We just looked up the relation with RangeVarGetRelidExtended(). There's
no reason to believe it might've been removed since then, especially
when we just locked it.

I'm not sure why it ever existed, but it's been dead for a long time.

* fix gpexpand Worker-thread hang problem
When using python 2.7, gpexpand will hang when the command "gpexpand -D gpadmin" is done. sys.exit calls thread.join() which waits for each thread to exit; The sub-thread Worker will still try getting from the WorkerPool Queue. 

however, when using python 2.6.2, it's OK. Maybe the Python threading module changed somehow.

The functions in memtuple.c were only called when building a column
binding struct. That's not a hot path, as that only gets done once, when
starting the executor, not at every row.

handleAckedPacket() is probably in a somewhat hot path, as it's called for
every received Ack interconnect packet. However, all the calls to it are
straight unconditional jumps, so branch prediction should make those
very cheap. Inlining them would increase the code size quite a bit, so the
compiler is probably making a good choice by refusing to inline them. Let's
not try to force it.

I'm seeing a few more warnings like this from tqual.c and tuplesort.c, but
those are in upstream code, so I'm reluctant to just remove the inline
attributes there. Should do something about those too, to reduce the noise,
but let's at least get these straightforward gpdb-specific cases fixed.

For reference, these are the warnings I was getting:

memtuple.c: In function ‘create_col_bind’:
memtuple.c:122:20: warning: inlining failed in call to ‘add_null_save_aligned’: call is unlikely and code size would grow [-Winline]
 static inline bool add_null_save_aligned(MemTupleAttrBinding *bind, short *null_save_aligned, int i, char next_attr_align)
                    ^
memtuple.c:241:10: warning: called from here [-Winline]
      if (add_null_save_aligned(previous_bind, colbind->null_saves_aligned, physical_col - 1, 'd'))
          ^
memtuple.c:122:20: warning: inlining failed in call to ‘add_null_save_aligned’: call is unlikely and code size would grow [-Winline]
 static inline bool add_null_save_aligned(MemTupleAttrBinding *bind, short *null_save_aligned, int i, char next_attr_align)
                    ^
memtuple.c:270:10: warning: called from here [-Winline]
      if (add_null_save_aligned(previous_bind, colbind->null_saves_aligned, physical_col - 1, 'i'))
          ^
memtuple.c:122:20: warning: inlining failed in call to ‘add_null_save_aligned’: call is unlikely and code size would grow [-Winline]
 static inline bool add_null_save_aligned(MemTupleAttrBinding *bind, short *null_save_aligned, int i, char next_attr_align)
                    ^
memtuple.c:308:10: warning: called from here [-Winline]
      if (add_null_save_aligned(previous_bind, colbind->null_saves_aligned, physical_col - 1, 's'))
          ^
memtuple.c:122:20: warning: inlining failed in call to ‘add_null_save_aligned’: call is unlikely and code size would grow [-Winline]
 static inline bool add_null_save_aligned(MemTupleAttrBinding *bind, short *null_save_aligned, int i, char next_attr_align)
                    ^
memtuple.c:354:10: warning: called from here [-Winline]
      if (add_null_save_aligned(previous_bind, colbind->null_saves_aligned, physical_col - 1, 'c'))
          ^
ic_udpifc.c: In function ‘handleAcks.isra.25’:
ic_udpifc.c:4370:1: warning: inlining failed in call to ‘handleAckedPacket’: call is unlikely and code size would grow [-Winline]
 handleAckedPacket(MotionConn *ackConn, ICBuffer *buf, uint64 now)
 ^
ic_udpifc.c:5177:3: warning: called from here [-Winline]
   handleAckedPacket(conn, buf, now);
   ^
ic_udpifc.c:4370:1: warning: inlining failed in call to ‘handleAckedPacket’: call is unlikely and code size would grow [-Winline]
 handleAckedPacket(MotionConn *ackConn, ICBuffer *buf, uint64 now)
 ^
ic_udpifc.c:5189:4: warning: called from here [-Winline]
    handleAckedPacket(conn, buf, now);
    ^
ic_udpifc.c:4370:1: warning: inlining failed in call to ‘handleAckedPacket’: call is unlikely and code size would grow [-Winline]
 handleAckedPacket(MotionConn *ackConn, ICBuffer *buf, uint64 now)
 ^
ic_udpifc.c:5073:4: warning: called from here [-Winline]
    handleAckedPacket(conn, buf, now);
    ^
ic_udpifc.c:4370:1: warning: inlining failed in call to ‘handleAckedPacket’: call is unlikely and code size would grow [-Winline]
 handleAckedPacket(MotionConn *ackConn, ICBuffer *buf, uint64 now)
 ^
ic_udpifc.c:5112:4: warning: called from here [-Winline]
    handleAckedPacket(conn, buf, now);
    ^

Also rename the argument to adjust_inherited_tlist() to what it is in
the upstream.

Now that it's purely GPDB code, let's be tidy. (Running pgindent on
files with mixed gpdb-specific and upstream code would easily mess up
the formatting of upstream code, if a different version of pgindent is
used, or if the gpdb-additions have changed indentation.)

tablecmds.c is huge, and it's inherited from upstream. This makes diffing
and merging with upstream a little bit easier.

To reduce the diff vs. upstream in pg_proc.h a little bit.

* Changes in gpexpand:
- Explicitly close the connection to the database before trying to stop
  it. Otherwise the database wouldn't stop due to active connection and
  the script will fail.
- Close the connection to the database before leaving the script.
  Otherwise it will not return to the command line

What we store in that field is not actually a valid "varbit" datum. If you
try to read it out as a varbit, it looks like a single "1" bit. That's
clearly bogus, but it's also problematic for pg_upgrade, because there's
no easy way to read the actual contents. There are functions in gp_toolkit
for reading it and decompressing it out, but it'd be much better to keep
it in compressed form in memory, as an uncompressed bitmap can be quite
large. Also, there's no easy way to restore the uncompressed bitmap back
into a valid visimap entry. We'll have to deal with it for the GPDB 4.3
to 5.0 upgrade, but let's fix the datatype in 5.0 so that the next upgrade
will be easier.

Bytea is a bit rough for this too. A custom "compressed bitmap" datatype
would probably be best. But this'll do for now.

Optimize s3key_writer to reuse chunkbuffer and upload the chunkbuffer to
S3 via multipart uploading.

Also remove CURLOPT_INFILESIZE_LARGE of curl because it's useless for
s3ext.
Signed-off-by: NAdam Lee <ali@pivotal.io>
Signed-off-by: NKuien Liu <kliu@pivotal.io>

In this test we may insert millions of rows onto S3, e.g., 1M rows occupy
55MB in plain CSV format. To make sure the regression is always successful,
we need to clean files in remote S3 bucket firstly, e.g, in pipeline:
`s3cmd --recursive del s3://s3test.pivotal.io/regress/s3write`

Signed-off-by: NPeifeng Qiu <pqiu@pivotal.io>

When post/put/head requests of RESTfulService fail,
try to re-execute them by multiple (default 3) times.
Signed-off-by: NKuien Liu <kliu@pivotal.io>

getUploadId(), uploadPartOfData() and completeMultiPart()
Signed-off-by: NHaozhou Wang <hawang@pivotal.io>