Issue a warning during the creation of hash indexes
Implement mxid_age() to compute multi-xid age

Report by Josh Berkus
pg_upgrade:  check for large object size compatibility
pg_upgrade: compare control version, not catalog version

Also modify test for the possibility the large object value might not
exist in the old cluster.

Fix for commit e1598a15f4fb0f076a6034d3d3debb9776aff07a
doc:  improve configuration management section

Patch by David Johnston

Backpatch through 9.4
Support older versions of "prove"

Apparently, older versions of "prove" (couldn't identify the exact
version from the changelog) don't look into the t/ directory for tests
by default, so specify it explicitly.
Handle old versions of Test::More

Really old versions of Test::More don't support subplans, so skip the
tests in that case.
Change the way latency is calculated with pgbench --rate option.

The reported latency values now include the "schedule lag" time, that is,
the time between the transaction's scheduled start time and the time it
actually started. This relates better to a model where requests arrive at a
certain rate, and we are interested in the response time to the end user or
application, rather than the response time of the database itself.

Also, when --rate is used, include the schedule lag time in the log output.

The --rate option is new in 9.4, so backpatch to 9.4. It seems better to
make this change in 9.4, while we're still in the beta period, than ship a
9.4 version that calculates the values differently than 9.5.
Simplify calculation of Poisson distributed delays in pgbench --rate mode.

The previous coding first generated a uniform random value between 0.0 and
1.0, then converted that to an integer between 1 and 10000, and divided that
again by 10000. Those conversions are unnecessary; we can use the double
value that pg_erand48() returns directly. While we're at it, put the logic
into a helper function, getPoissonRand().

The largest delay generated by the old coding was about 9.2 times the
average, because of the way the uniformly distributed value used for the
calculation was truncated to 1/10000 granularity. The new coding doesn't
have such clamping. With my laptop's DBL_MIN value, the maximum delay with
the new coding is about 700x the average. That seems acceptable - any
reasonable pgbench session should last long enough to average that out.

Backpatch to 9.4.
Silence compiler warning on Windows.

David Rowley.
Fix Windows build.

I renamed a variable, but missed an #ifdef WIN32 block.
Add missing volatile qualifier.

Yet another silly mistake in 0709b7ee72e4bc71ad07b7120acd117265ab51d0,
again found by buildfarm member castoroides.
improve hash creation warning message

This improves the wording of commit 84aa8ba128a08e6fdebb2497c7a79ebf18093e12.

Report by Kevin Grittner
Remove dead InRecovery check.

With the new B-tree incomplete split handling in 9.4, _bt_insert_parent is
never called in recovery.
Merge branch 'master' into transition
pg_upgrade:  adjust C comments
Add 'ignore_nulls' option to row_to_json

Provide an option to skip NULL values in a row when generating a JSON
object from that row with row_to_json.  This can reduce the size of the
JSON object in cases where columns are NULL without really reducing the
information in the JSON object.

This also makes row_to_json into a single function with default values,
rather than having multiple functions.  In passing, change array_to_json
to also be a single function with default values (we don't add an
'ignore_nulls' option yet- it's not clear that there is a sensible
use-case there, and it hasn't been asked for in any case).

Pavel Stehule
Fix vacuumdb --analyze-in-stages --all order

When running vacuumdb --analyze-in-stages --all, it needs to run the
first stage across all databases before the second one, instead of
running all stages in a database before processing the next one.

Also respect the --quiet option with --analyze-in-stages.
Fix JSON regression tests.

Commit 95d737ff45a38809130a2c633d9e6bc26c825036 neglected to update
expected/json_1.out.  Per buildfarm.
Fix power_var_int() for large integer exponents.

The code for raising a NUMERIC value to an integer power wasn't very
careful about large powers.  It got an outright wrong answer for an
exponent of INT_MIN, due to failure to consider overflow of the Abs(exp)
operation; which is fixable by using an unsigned rather than signed
exponent value after that point.  Also, even though the number of
iterations of the power-computation loop is pretty limited, it's easy for
the repeated squarings to result in ridiculously enormous intermediate
values, which can take unreasonable amounts of time/memory to process,
or even overflow the internal "weight" field and so produce a wrong answer.
We can forestall misbehaviors of that sort by bailing out as soon as the
weight value exceeds what will fit in int16, since then the final answer
must overflow (if exp > 0) or underflow (if exp < 0) the packed numeric
format.

Per off-list report from Pavel Stehule.  Back-patch to all supported
branches.