A data-type-based solution, which is much cleaner and more bulletproof,
will follow shortly.  It seemed best to make this a separate commit though.

Per KOIZUMI Satoru.

type.  Per KOIZUMI Satoru.

SI invalidation events, rather than indirectly through the relcache.

In the previous coding, we had to flush a composite-type typcache entry
whenever we discarded the corresponding relcache entry.  This caused problems
at least when testing with RELCACHE_FORCE_RELEASE, as shown in recent report
from Jeff Davis, and might result in real-world problems given the kind of
unexpected relcache flush that that test mechanism is intended to model.

The new coding decouples relcache and typcache management, which is a good
thing anyway from a structural perspective.  The cost is that we have to
search the typcache linearly to find entries that need to be flushed.  There
are a couple of ways we could avoid that, but at the moment it's not clear
it's worth any extra trouble, because the typcache contains very few entries
in typical operation.

Back-patch to 8.2, the same as some other recent fixes in this general area.
The patch could be carried back to 8.0 with some additional work, but given
that it's only hypothetical whether we're fixing any problem observable in
the field, it doesn't seem worth the work now.

Per discussion.

and contains operators.

initialize the rd_backend field of a fake Relation entry correctly.
Fortunately, that is easy, since only non-temp relations should ever be
mentioned in the WAL stream.

Issue reported by Harald Kolb, patch by Fujii Masao, review by me.

Very minor issue, though this is required for a later patch.
Reported by Heikki Linnakangas.

This patch changes _bt_split() and _bt_pagedel() to throw a plain ERROR,
rather than PANIC, for several cases that are reported from the field
from time to time:
* right sibling's left-link doesn't match;
* PageAddItem failure during _bt_split();
* parent page's next child isn't right sibling during _bt_pagedel().
In addition the error messages for these cases have been made a bit
more verbose, with additional values included.

The original motivation for PANIC here was to capture core dumps for
subsequent analysis.  But with so many users whose platforms don't capture
core dumps by default, or who are unprepared to analyze them anyway, it's hard
to justify a forced database restart when we can fairly easily detect the
problems before we've reached the critical sections where PANIC would be
necessary.  It is not currently known whether the reports of these messages
indicate well-hidden bugs in Postgres, or are a result of storage-level
malfeasance; the latter possibility suggests that we ought to try to be more
robust even if there is a bug here that's ultimately found.

Backpatch to 8.2.  The code before that is sufficiently different that
it doesn't seem worth the trouble to back-port further.

Spotted by Dmitriy Igrishin.  Back-patch to 8.2, which is when the PREPARE
statement was improved to allow parameter types to be omitted.

Peter Eisentraut reports that some bits of the "address" variable
in get_object_address() give "may be used uninitialized" warnings;
this likes the only excuse his compiler could have for thinking
that's possible.

Review by Alvaro Herrera, KaiGai Kohei, and Tom Lane.

which is perhaps not a terribly good spot for it but there doesn't seem to be
a better place.  Also add a source-code comment pointing out a couple reasons
for having a separate lock file.  Per suggestion from Greg Smith.

of constraints.

Kevin Grittner

Egypt and Palestine.  Added new names for two Micronesian timezones:
Pacific/Chuuk is now preferred over Pacific/Truk (and the preferred
abbreviation is CHUT not TRUT) and Pacific/Pohnpei is preferred over
Pacific/Ponape.  Historical corrections for Finland.

original misleadingly suggests that only access is meant, causing confusion.
Per recent trouble report by Robert McGehee on pgsql-admin.

returning "record" actually do have the same rowtype.  This is needed because
the parser can't realistically enforce that they will all have the same typmod,
as seen in a recent example from David Wheeler.

Back-patch to 8.0, which is as far back as we have the notion of RECORD
subtypes being distinguished by typmod.  Wheeler's example depends on
8.4-and-up features, but I suspect there may be ways to provoke similar
failures before 8.4.

build tree.  If we actually build the docs in the VPATH tree, those dirs
will get created then; but if they're present and empty, they capture the
vpathsearch searches in "make install", preventing installation of prebuilt
docs that might exist in the source tree.  Per bug #5595 from Dmtiriy Igrishin.
Fix based on idea from Peter Eisentraut.

questionable reliability;  information moved to a wiki:

	http://wiki.postgresql.org/wiki/Incrementally_Updated_Backups

Backpatch to 9.0.

While at it, copy-edit the description of prefix-match marker support in
synonym dictionaries, and clarify the description of the default unaccent
dictionary a bit more.

It turns out that some platforms return ENOMEM for a request that violates
SHMALL, whereas we were assuming that ENOSPC would always be used for that.
Apparently the latter is a Linuxism while ENOMEM is the BSD tradition.
Extend the ENOMEM hint to suggest that raising SHMALL might be needed.
Per gripe from A.M.

Backpatch to 9.0, but not further, because this doesn't seem important
enough to warrant creating extra translation work in the stable branches.
(If it were, we'd have figured this out years ago.)

This is reproducibly possible in Python 2.7 if the user turned
PendingDeprecationWarning into an error, but it's theoretically also possible
in earlier versions in case of exceptional conditions.

backpatched to 8.0

portability mistake as always.  Per buildfarm member pika.

Note: as usual, bug fixes that were also applied in back branches are not
considered material to include in a new major release's notes.

but only in VERBOSE mode.  Per discussion.

files automatically.  Otherwise, the following could happen: When
starting from a clean source tree, the first build would delete the
intermediate file, but also create the dependency file, which
mentions the intermediate file, thus making it non-intermediate.
The second build will then need to rebuild the now non-intermediate
missing file.  So the second build will do work even though nothing
had changed.  One place where this happens is the .c -> .o -> .so
chain for some contrib modules.

Backpatch to 9.0.X.