Move pqsignal() to libpgport.

We had two copies of this function in the backend and libpq, which was
already pretty bogus, but it turns out that we need it in some other
programs that don't use libpq (such as pg_test_fsync).  So put it where
it probably should have been all along.  The signal-mask-initialization
support in src/backend/libpq/pqsignal.c stays where it is, though, since
we only need that in the backend.
Fix inclusions in pg_receivexlog.c.

Apparently this was depending on pqsignal.h for <signal.h>.
Not sure why I didn't see the failure on my other machine.
Fix inclusions in pgbench.c.

Apparently this was depending on pqsignal.h for <signal.h>.
Not sure why I didn't see the failure on my other machine.
initdb needs pqsignal() even on Windows.

I had thought we weren't using this version of pqsignal() at all on
Windows, but that's wrong --- initdb is using it (and coping with the
POSIX-ish semantics of bare signal() :-().  So allow the file to be
built in WIN32+FRONTEND case, and add it to the MSVC build logic.
Re-include pqsignal() in libpq.

We need this in non-ENABLE_THREAD_SAFETY builds, and also to satisfy
the exports.txt entry; while it might be a good idea to remove the
latter, I'm hesitant to do so except in the context of an intentional
ABI break.  At least we don't have a separately maintained source file
for it anymore.
Use pqsignal() in contrib programs rather than calling signal(2) directly.

The semantics of signal(2) are more variable than one could wish; in
particular, on strict-POSIX platforms the signal handler will be reset
to SIG_DFL when the signal is delivered.  This demonstrably breaks
pg_test_fsync's use of SIGALRM.  The other changes I made are not
absolutely necessary today, because the called handlers all exit the
program anyway.  But it seems like a good general practice to use
pqsignal() exclusively in Postgres code, now that we have it available
everywhere.
Improve signal-handler lockout mechanism in timeout.c.

Rather than doing a fairly-expensive setitimer() call to prevent interrupts
from happening, let's just invent a simple boolean flag that the signal
handler is required to check.  This is not only faster but considerably
more robust than before, since the previous code effectively assumed that
only ITIMER_REAL events would ever fire the SIGALRM handler, which is
obviously something that can be broken easily by third-party code.

Zoltán Böszörményi and Tom Lane
Extend object-access hook machinery to support post-alter events.

This also slightly widens the scope of what we support in terms of
post-create events.

KaiGai Kohei, with a few changes, mostly to the comments, by me
Increase timeout delays in new timeouts isolation test.

Buildfarm member friarbird doesn't like this test as-committed, evidently
because it's so slow that the test framework doesn't reliably notice that
the backend is waiting before the timeout goes off.  (This is not totally
surprising, since friarbird builds with -DCLOBBER_CACHE_ALWAYS.)  Increase
the timeout delay from 1 second to 2 in hopes of resolving that problem.
Remove PageSetTLI and rename pd_tli to pd_checksum
Remove use of PageSetTLI() from all page manipulation functions
and adjust README to indicate change in the way we make changes
to pages. Repurpose those bytes into the pd_checksum field and
explain how that works in comments about page header.

Refactoring ahead of actual feature patch which would make use
of the checksum field, arriving later.

Jeff Davis, with comments and doc changes by Simon Riggs
Direction suggested by Robert Haas; many others providing
review comments.
Add pageinspect--1.1.sql for checksum changes
Add pageinspect--1.0--1.sql for checksum changes
Improve documentation of EXTRACT(WEEK).

The docs showed that early-January dates can be considered part of the
previous year for week-counting purposes, but failed to say explicitly
that late-December dates can also be considered part of the next year.
Fix that, and add a cross-reference to the "isoyear" field.  Per bug
#7967 from Pawel Kobylak.
Add reliability docs about storage/memory corruptions.
Add section to the Reliability section about what is and is not protected for
various file types.
Further edits welcome.

Designed to allow 1-2 line change when/if checksums are committed.

Inspired by docs written by Jeff Davis, though completely different from his
patch.
Correction that 2pc state files use CRC-32.

Jeff Davis
Clarify assumption of filesystem metadata integrity.

Jeff Davis
Use ORDER BY on matview definitions were needed for stable plans.

Per report from Hadi Moshayedi of matview regression test failure
with optimization of aggregates.  A few ORDER BY clauses improve
code coverage for matviews while solving that problem.
Bump up timeout delays some more in timeouts isolation test.

The buildfarm members using -DCLOBBER_CACHE_ALWAYS still don't like this
test.  Some experimentation shows that on my machine, isolationtester's
query to check for "waiting" state takes 2 to 2.5 seconds to bind+execute
under -DCLOBBER_CACHE_ALWAYS.  Set the timeouts to 5 seconds to leave some
headroom for possibly-slower buildfarm critters.

Really we ought to fix the "waiting" query, which is not only horridly
slow but outright wrong in detail; and then maybe we can back off these
timeouts.  But right now I'm just trying to get the buildfarm green again.
Allow extracting machine-readable object identity

Introduce pg_identify_object(oid,oid,int4), which is similar in spirit
to pg_describe_object but instead produces a row of machine-readable
information to uniquely identify the given object, without resorting to
OIDs or other internal representation.  This is intended to be used in
the event trigger implementation, to report objects being operated on;
but it has usefulness of its own.

Catalog version bumped because of the new function.
Fix "element <@ range" cost estimation.

The statistics-based cost estimation patch for range types broke that, by
incorrectly assuming that the left operand of all range oeprators is a
range. That lead to a "type x is not a range type" error. Because it took so
long for anyone to notice, add a regression test for that case.

We still don't do proper statistics-based cost estimation for that, so you
just get a default constant estimate. We should look into implementing that,
but this patch at least fixes the regression.

Spotted by Tom Lane, when testing query from Josh Berkus.