dump IDs, because the array we're using is sized according to the highest
dump ID actually defined in the archive file.  In a partial dump there could
be references to higher dump IDs that weren't dumped.  Treat these the same
as references to in-range IDs that weren't dumped.  (The whole thing is a
bit scary because the missing objects might have been part of dependency
chains, which we won't know about.  Not much we can do though --- throwing
an error is probably overreaction.)

Also, reject parallel restore with pre-1.8 archive version (made by pre-8.0
pg_dump).  In these old versions the dependency entries are OIDs, not dump
IDs, and we don't have enough information to interpret them.

Per bug #5288 from Jon Erdman.

when the planner splits apart a ROW(...) IS NULL test, the argisrow values
of the component tests have to be determined from the component field types,
not copied from the original NullTest (in which argisrow is surely true).

statistics of the bgwriter.

Greg Smith

wrappers around the pg_relation_size() function.

Bernd Helmle, reviewed by Greg Smith

This is the last EXECUTE-like plpgsql statement that was missing
the capability of inserting parameter values via USING.

Pavel Stehule, reviewed by Itagaki Takahiro

cases that are not part of the enum's definition.

EXISTS that contains a WITH clause.  This would usually lead to a
"could not find CTE" error later in planning, because the WITH wouldn't
get processed at all.  Noted while playing with an example from Ken Marshall.

Vyacheslav Kalinin <vka@mgcp.com>

after it's released its reference count for the cached plan.  There are
code paths that might try to examine the plan list before noticing that
the portal is already in aborted state.  Report and diagnosis by Tatsuo
Ishii, though this isn't exactly his proposed patch.

constraints and was lacking a couple of other interesting details.

pg_constraint before searching pg_trigger.  This allows saner handling of
corner cases; in particular we now say "constraint is not deferrable"
rather than "constraint does not exist" when the command is applied to
a constraint that's inherently non-deferrable.  Per a gripe several months
ago from hubert depesz lubaczewski.

To make this work without breaking user-defined constraint triggers,
we have to add entries for them to pg_constraint.  However, in return
we can remove the pgconstrname column from pg_constraint, which represents
a fairly sizable space savings.  I also replaced the tgisconstraint column
with tgisinternal; the old meaning of tgisconstraint can now be had by
testing for nonzero tgconstraint, while there is no other way to get
the old meaning of nonzero tgconstraint, namely that the trigger was
internally generated rather than being user-created.

In passing, fix an old misstatement in the docs and comments, namely that
pg_trigger.tgdeferrable is exactly redundant with pg_constraint.condeferrable.
Actually, we mark RI action triggers as nondeferrable even when they belong to
a nominally deferrable FK constraint.  The SET CONSTRAINTS code now relies on
that instead of hard-coding a list of exception OIDs.

posix_fadvise and other file-related functions can depend on _LARGEFILE_SOURCE
and/or _FILE_OFFSET_BITS.  Per report from Robert Treat.

Back-patch to 8.4.  This has been wrong all along, but we weren't really using
posix_fadvise in anger before, and AC_FUNC_FSEEKO seems to mask the issue well
enough for that function.

argument, per warnings from buildfarm member pika.  Also clean up code
formatting a trifle.

didn't work in EXEC_BACKEND case.

against concurrent reconnection. Failure during testing showed issue
was possible, even though earlier analysis seemed to indicate it
would not be required. Use LockSharedObjectForSession() before
ResolveRecoveryConflictWithDatabase() and hold lock until end of
processing for that WAL record. Simple approach to avoid introducing
further bugs at this stage of development on an improbable issue.

Mimic the Python interpreter's own logic for printing exceptions instead
of just using the straight str() call, so that
you get

    plpy.SPIError

instead of

    <class 'plpy.SPIError'>

and for built-in exceptions merely

    UnicodeEncodeError

Besides looking better this cuts down on the endless version differences
in the regression test expected files.

Noticed by Andres Freund

Conflict reason is passed through directly to the backend, so we can
take decisions about the effect of the conflict based upon the local
state. No specific changes, as yet, though this prepares for later work.
CancelVirtualTransaction() sends signals while holding ProcArrayLock.
Introduce errdetail_abort() to give message detail explaining that the
abort was caused by conflict processing. Remove CONFLICT_MODE states
in favour of using PROCSIG_RECOVERY_CONFLICT states directly, for clarity.

the BlockSig/UnBlockSig declaration have to be PGDLLIMPORT'ified.
Per buildfarm results.

parse analysis phase, rather than at execution time.  This makes parameter
handling work the same as it does in ordinary plannable queries, and in
particular fixes the incompatibility that Pavel pointed out with plpgsql's
new handling of variable references.  plancache.c gets a little bit
grottier, but the alternatives seem worse.

process, after src/interfaces, because it depends on libpq. Also add
missing lines for clean etc. targets

Report from Boszormenyi Zoltan.

Added correct error handling in DESCRIBE statement processing by Boszormenyi Zoltan <zb@cybertec.at>.

This includes two new kinds of postmaster processes, walsenders and
walreceiver. Walreceiver is responsible for connecting to the primary server
and streaming WAL to disk, while walsender runs in the primary server and
streams WAL from disk to the client.

Documentation still needs work, but the basics are there. We will probably
pull the replication section to a new chapter later on, as well as the
sections describing file-based replication. But let's do that as a separate
patch, so that it's easier to see what has been added/changed. This patch
also adds a new section to the chapter about FE/BE protocol, documenting the
protocol used by walsender/walreceivxer.

Bump catalog version because of two new functions,
pg_last_xlog_receive_location() and pg_last_xlog_replay_location(), for
monitoring the progress of replication.

Fujii Masao, with additional hacking by me

of this are to centralise the conflict code to allow further change,
as well as to allow passing through the full reason for the conflict
through to the conflicting backends. Backend state alters how we
can handle different types of conflict so this is now required.
As originally suggested by Heikki, no longer optional.

rather than trying to implement the equivalent logic by hand.  The motivation
for the original coding appears to have been to check with the effective uid's
permissions not the real uid's; but there is no longer any difference, because
we don't run the postmaster setuid (indeed, main.c enforces that they're the
same).  Using access() means we will get it right in situations the original
coding failed to handle, such as ACL-based permissions.  Besides it's a lot
shorter, cleaner, and more thread-safe.  Per bug #5275 from James Bellinger.

underlying catalog not only the index itself.  Otherwise, if the cache
load process touches the catalog (which will happen for many though not
all of these indexes), we are locking index before parent table, which can
result in a deadlock against processes that are trying to lock them in the
normal order.  Per today's failure on buildfarm member gothic_moth; it's
surprising the problem hadn't been identified before.

Back-patch to 8.2.  Earlier releases didn't have the issue because they
didn't try to lock these indexes during load (instead assuming that they
couldn't change schema at all during multiuser operation).