Fix handling of OID wraparound while in standalone mode.

If OID wraparound should occur while in standalone mode (unlikely but
possible), we want to advance the counter to FirstNormalObjectId not
FirstBootstrapObjectId.  Otherwise, user objects might be created with OIDs
in the system-reserved range.  That isn't immediately harmful but it poses
a risk of conflicts during future pg_upgrade operations.

Noted by Andres Freund.  Back-patch to all supported branches, since all of
them are supported sources for pg_upgrade operations.
doc: Fix order of options on pgbench man page
pg_upgrade: Replace tabs in output string constants by spaces
doc: Fix some whitespace issues in the man pages
doc: Add \dm command to psql man page
Allow CREATE FOREIGN TABLE to include SERIAL columns.

The behavior is that the required sequence is created locally, which is
appropriate because the default expression will be evaluated locally.
Per gripe from Brad Nicholson that this case was refused with a confusing
error message.  We could have improved the error message but it seems
better to just allow the case.

Also, remove ALTER TABLE's arbitrary prohibition against being applied to
foreign tables, which was pretty inconsistent considering we allow it for
views, sequences, and other relation types that aren't even called tables.
This is needed to avoid breaking pg_dump, which sometimes emits column
defaults using separate ALTER TABLE commands.  (I think this can happen
even when the default is not associated with a sequence, so that was a
pre-existing bug once we allowed column defaults for foreign tables.)
Fix some uses of "the quick brown fox".

If we're going to quote a well-known pangram, we should quote it
accurately.  Per gripe from Thom Brown.
Fix fd.c to preserve errno where needed.

PathNameOpenFile failed to ensure that the correct value of errno was
returned to its caller after a failure (because it incorrectly supposed
that free() can never change errno).  In some cases this would result
in a user-visible failure because an expected ENOENT errno was replaced
with something else.  Bogus EINVAL failures have been observed on OS X,
for example.

There were also a couple of places that could mangle an important value
of errno if FDDEBUG was defined.  While the usefulness of that debug
support is highly debatable, we might as well make it safe to use,
so add errno save/restore logic to the DO_DB macro.

Per bug #8167 from Nelson Minar, diagnosed by RhodiumToad.
Back-patch to all supported branches.
Fix crash when trying to display a NOTIFY rule action.

Fixes oversight in commit 2ffa740be9d96a3743ecb7e42391c53d0760c65a.
Per report from Josh Kupershmidt.

I think we've broken this case before, so let's add a regression test
this time.
Add support for in-memory out-of-line stored toast data

For some use-cases like logical decoding of wal or avoidance of repeated
detoasting of toast tuples it is useful to represent varlenas that are stored
in memory but outside of a HeapTuple. E.g. because it is impossible to allocate
a memory chunk for the whole tuple at once or because the overhead of repeated
detoasting from disk is noticeable.

For that support "indirect" toast tuples which point to another 'struct
varlena' in memory. That referenced tuple can be short, compressed or normal.

As there are no further flag bits available to discern such an indirection from
the other forms inside the original Datum we reuse the VARATT_IS_EXTERNAL
representation for this which apt because they are also
out-of-line. Unfortunately only varatt_1b_e.va_length is available to discern
toast and indirection toast tuple, so they must be different for both. A
StaticAssertStm to make sure of that is included.
wal_decoding: Add pg_xlog_wait_remote_{apply,receive} functions

We want to use these in isolationtester tests, but they're more
generally useful for "inter-node synchronisation".
wal_decoding: Add a new RELFILENODE syscache to fetch a pg_class entry via (reltablespace, relfilenode)

This cache is theoretically problematic because formally indexes used by
syscaches needs to be unique, this one is not. This is "just" because of
0/InvalidOid are stored in pg_class.relfilenode for nailed/shared catalog
relations. This syscache will never be queried for InvalidOid relfilenodes
however so it seems to be safe even if it bends the rules somewhat.

It might be nicer to add infrastructure to do this properly, like using a
partial index, its not clear what the best way to do this is though and the
benefit very well might not be worth the overhead.

Needs a CATVERSION bump.
wal_decoding: Add RelationMapFilenodeToOid function to relmapper.c

This function maps (reltablespace, relfilenode) to the table oid and thus acts
as a reverse of RelationMapOidToFilenode.
wal_decoding: Add pg_relation_by_filenode to lookup up a relation by (tablespace, filenode)

This requires the previously added RELFILENODE syscache and the added
RelationMapFilenodeToOid function added in previous two commits.
wal_decoding: Introduce InvalidCommandId and declare that to be the new maximum for CommandCounterIncrement

This is useful to be able to represent a CommandId thats invalid. There was no
such value before.

This decreases the possible number of subtransactions by one which seems
unproblematic. Its also not a problem for pg_upgrade because cmin/cmax are
never looked at outside the context of their own transaction (spare timetravel
access, but thats new anyway).
wal_decoding: Adjust all *Satisfies routines to take a HeapTuple instead of a HeapTupleHeader

For the regular satisfies routines this is needed in prepareation of logical
decoding. I changed the non-regular ones for consistency as well.

The naming between htup, tuple and similar is rather confused, I could not find
any consistent naming anywhere.

This is preparatory work for the logical decoding feature which needs to be
able to get to a valid relfilenode from when checking the visibility of a
tuple.
wal_decoding: Allow walsender's to connect to a specific database

Currently the decision whether to connect to a database or not is made by
checking whether the passed "dbname" parameter is "replication". Unfortunately
this makes it impossible to connect a to a database named replication...

This is useful for future walsender commands which need database interaction.
wal_decoding: Add alreadyLocked parameter to GetOldestXminNoLock

This is useful because it allows to compute the current OldestXmin while
already holding the procarray lock which enables setting the own xmin horizon
safely.
wal_decoding: Log xl_running_xact's at a higher frequency than checkpoints are done

Do so in the background writer which seems to be the best choice as its
regularly running and shouldn't be busy for too long without getting back into
its main loop.

Also mark xl_standby records as being relevant for async commit so the wal
writer writes them out soonish.

This might also be beneficial for HS as it would make it faster to hit a spot
where no (old) transactions are running anymroe.
wal_decoding: copydir: make fsync_fname public

This probably should be somewhere else, its a generally useful function, not
really related to copying directories. fd.[ch]?