Free PQresult on error in pg_receivexlog.

The leak is fairly small and rare, but a leak nevertheless.

Per Coverity report. Backpatch to 9.2, where pg_receivexlog was added.
pg_basebackup shares the code, but it always exits on error, so there is
no real leak.
Fix typo in test_shm_mq document.

Amit Langote
Ignore config.pl and buildenv.pl in src/tools/msvc.

config.pl and buildenv.pl can be used to customize build settings when
using MSVC.  They should never get committed into the common source tree.

Back-patch to 9.0; it looks like the rules were different in 8.4.

Michael Paquier
Be more wary in choice of timezone names to test make_timestamptz with.

America/Metlakatla hasn't been in the IANA database all that long, so
some installations might not have it.  It does seem worthwhile to test
with a fractional-minute GMT offset, but we can get that from almost
any pre-1900 date; I chose Europe/Paris, whose LMT offset from Greenwich
should be pretty darn well established.

Also, assuming that Mars/Mons_Olympus will never be in the IANA database
seems less than future-proof, so let's use a more fanciful location for
the bad-zone-name check.

Per complaint from Christoph Berg.
doc: 9.4 release note adjustments

Report by Nicolas Barbier, Tatsuo Ishii, MauMau
docs:  use structfield instead of structname in 9.4 release notes

Where appropriate
Add Valgrind suppression for reorderbuffer padding bytes.

Andres Freund
Initialize padding bytes in btree_gist varbit support.

The code expands a varbit gist leaf key to a node key by copying the bit
data twice in a varlen datum, as both the lower and upper key. The lower key
was expanded to INTALIGN size, but the padding bytes were not initialized.
That's a problem because when the lower/upper keys are compared, the padding
bytes are used compared too, when the values are otherwise equal. That could
lead to incorrect query results.

REINDEX is advised for any btree_gist indexes on bit or bit varying data
type, to fix any garbage padding bytes on disk.

Per Valgrind, reported by Andres Freund. Backpatch to all supported
versions.
Fix harmless access to uninitialized memory.

When cache invalidations arrive while ri_LoadConstraintInfo() is busy
filling a new cache entry, InvalidateConstraintCacheCallBack() compares
the - not yet initialized - oidHashValue field with the to-be-invalidated
hash value. To fix, check whether the entry is already marked as invalid.

Andres Freund
docs:  9.4 release notes adjustments

Patch by Andres Freund, slight adjustments by me
doc:  auto-updatable view adjustments for 9.4 release notes

Report by Dean Rasheed
docs:  mention windows quoting change in 9.4 release notes

Report by Heikki Linnakangas
Make initdb throw error for bad locale values.

Historically we've printed a complaint for a bad locale setting, but then
fallen back to the environment default.  Per discussion, this is not such
a great idea, because rectifying an erroneous locale choice post-initdb
(perhaps long after data has been loaded) could be enormously expensive.
Better to complain and give the user a chance to double-check things.

The behavior was particularly bad if the bad setting came from environment
variables rather than a bogus command-line switch: in that case not only
was there a fallback to C/SQL_ASCII, but the printed complaint was quite
unhelpful.  It's hard to be entirely sure what variables setlocale looked
at, but we can at least give a hint where the problem might be.

Per a complaint from Tomas Vondra.
doc: fix typo in 9.4 release note comments

Patch by Sergey Muraviov
doc:  fix 9.4 release notes typo

Report by Dean Rasheed
Code review for recent changes in relcache.c.

rd_replidindex should be managed the same as rd_oidindex, and rd_keyattr
and rd_idattr should be managed like rd_indexattr.  Omissions in this area
meant that the bitmapsets computed for rd_keyattr and rd_idattr would be
leaked during any relcache flush, resulting in a slow but permanent leak in
CacheMemoryContext.  There was also a tiny probability of relcache entry
corruption if we ran out of memory at just the wrong point in
RelationGetIndexAttrBitmap.  Otherwise, the fields were not zeroed where
expected, which would not bother the code any AFAICS but could greatly
confuse anyone examining the relcache entry while debugging.

Also, create an API function RelationGetReplicaIndex rather than letting
non-relcache code be intimate with the mechanisms underlying caching of
that value (we won't even mention the memory leak there).

Also, fix a relcache flush hazard identified by Andres Freund:
RelationGetIndexAttrBitmap must not assume that rd_replidindex stays valid
across index_open.

The aspects of this involving rd_keyattr date back to 9.3, so back-patch
those changes.
pg_upgrade:  error out on 'line' data type usage

The data type internal format changed in 9.4.  Also mention this in the
9.4 release notes.
Fix version check for pg_upgrade line type crosscheck.

Per buildfarm.
pg_update:  slight major version adjustment
In initdb, ensure stdout/stderr buffering behavior is what we expect.

Since this program may print to either stdout or stderr, the relative
ordering of its messages depends on the buffering behavior of those files.
Force stdout to be line-buffered and stderr to be unbuffered, ensuring
that the behavior will match standard Unix interactive behavior, even
when stdout and stderr are rerouted to a file.

Per complaint from Tomas Vondra.  The particular case he pointed out is
new in HEAD, but issues of the same sort could arise in any branch with
other error messages, so back-patch to all branches.

I'm unsure whether we might not want to do this in other client programs
as well.  For the moment, just fix initdb.