Also set the documented release date to 2011-09-12.

Trailing-zero stripping applied by the FM specifier could strip zeroes
to the left of the decimal point, for a format with no digit positions
after the decimal point (such as "FM999.").

Reported and diagnosed by Marti Raudsepp, though I didn't use his patch.

Backpatch to 9.1.

By Hiroshi Saito

because its internal format was changed in 8.4.

Backpatch to 9.0 and 9.1.

Report by depesz, diagnosis by Tom.

Per Euler Taveira de Oliveira.

With 9.1's use of Params to pass down values from NestLoop join nodes
to their inner plans, it is possible for a Param to have type RECORD, in
which case the set of fields comprising the value isn't determinable by
inspection of the Param alone.  However, just as with a Var of type RECORD,
we can find out what we need to know if we can locate the expression that
the Param represents.  We already knew how to do this in get_parameter(),
but I'd overlooked the need to be able to cope in get_name_for_var_field(),
which led to EXPLAIN failing with "record type has not been registered".

To fix, refactor the search code in get_parameter() so it can be used by
both functions.

Per report from Marti Raudsepp.

will expaned undefined identifiers.

not expanded.

Bump catalog version number to force initdb for all tablespaces.

they wrap toward year 2020, rather than the inconsistent behavior we had
before.

Backpatch to 9.0 and 9.1.

Patch from Josh Kupershmidt.

Maintain difference between subtransaction release and commit introduced
by earlier patch.

Adds additional test for active walsenders and closes a race
condition for when we failover when a new walsender was connecting.

Reported and fixed bu Fujii Masao. Review by Heikki Linnakangas

fields.

Backpatch to 9.0 and 9.1.

Report from Pavel Stehule, patch from Josh Kupershmidt

Per Peter.

pgpass.

Backpatch to 9.1.

Found by gcc -Wlogical-op

Backpatch to 9.0 and 9.1.

The code in shift_jis_20042euc_jis_2004() would fetch two bytes even when
only one remained in the string.  Since conversion functions aren't
supposed to assume null-terminated input, this poses a small risk of
fetching past the end of memory and incurring SIGSEGV.  No such crash has
been identified in the field, but we've certainly seen the equivalent
happen in other code paths, so patch this one all the way back.

Report and patch by Noah Misch.

Since the last couple of columns of pg_type are often NULL,
sizeof(FormData_pg_type) can be an overestimate of the actual size of the
tuple data part.  Therefore memcpy'ing that much out of the catalog cache,
as analyze.c was doing, poses a small risk of copying past the end of
memory and incurring SIGSEGV.  No such crash has been identified in the
field, but we've certainly seen the equivalent happen in other code paths,
so patch this one all the way back.

Per valgrind testing by Noah Misch, though this is not his proposed patch.
I chose to use SearchSysCacheCopy1 rather than inventing special-purpose
infrastructure for copying only the minimal part of a pg_type tuple.

Backpatch to 9.0 and 9.1.

Report from depstein@alliedtesting.com.

We've now seen more than one gripe from somebody who didn't get the memo
about how to install contrib modules in 9.1.  Try to make it a little more
prominent that you aren't supposed to call the scripts directly anymore.

This example wasn't updated when we changed the behavior of bpcharlen()
in 8.0, nor when we changed the number of parameters taken by the bpchar()
cast function in 7.3.  Per report from lsliang.

processes.

Backpatch to 9.1 and 9.0.

Submitted by Anton Yuzhaninov, confirmed by Robert Haas

session-local objects.

It used to say

ERROR:  invalid byte sequence for encoding "UTF8": 0xdb24

Change this to

ERROR:  invalid byte sequence for encoding "UTF8": 0xdb 0x24

to make it clear that this is a byte sequence and not a code point.

Also fix the adjacent "character has no equivalent" message that has
the same issue.

Backpatch to 9.1.

DST law changes in Canada, Egypt, Russia, Samoa, South Sudan.

characters.

Backpatch to 9.0 and 9.1.

The $(PERL) macro will be set by configure if it finds perl at all,
but $(perl_privlibexp) isn't configured unless you said --with-perl.
This results in confusing error messages if someone cd's into
src/pl/plperl and tries to build there despite the configure omission,
as reported by Tomas Vondra in bug #6198.  Add simple checks to
provide a more useful report, while not disabling other use of the
makefile such as "make clean".

Back-patch to 9.0, which is as far as the patch applies easily.

Formerly, callers tested for DEFAULT_NUM_DISTINCT, which had the problem
that a perfectly solid estimate might be mistaken for a content-free
default.

If a sub-select's output column is a simple Var, recursively look for
statistics applying to that Var, and use them if available.  The need for
this was foreseen ages ago, but we didn't have enough infrastructure to do
it with reasonable speed until just now.

We punt and stick with default estimates if the subquery uses set
operations, GROUP BY, or DISTINCT, since those operations would change the
underlying column statistics (particularly, the relative frequencies of
different values) beyond recognition.  This means that the types of
sub-selects for which this improvement applies are fairly limited, since
most subqueries satisfying those restrictions would have gotten flattened
into the parent query anyway.  But it does help for some cases, such as
subqueries with ORDER BY or LIMIT.

Since the subroots will surely link back to the same glob struct, this
necessarily leads to infinite recursion.  Doh.  Found while trying to
debug some other code.

walsender.h should depend on xlog.h, not vice versa.  (Actually, the
inclusion was circular until a couple hours ago, which was even sillier;
but Bruce broke it in the expedient rather than logically correct
direction.)  Because of that poor decision, plus blind application of
pgrminclude, we had a situation where half the system was depending on
xlog.h to include such unrelated stuff as array.h and guc.h.  Clean up
the header inclusion, and manually revert a lot of what pgrminclude had
done so things build again.

This episode reinforces my feeling that pgrminclude should not be run
without adult supervision.  Inclusion changes in header files in particular
need to be reviewed with great care.  More generally, it'd be good if we
had a clearer notion of module layering to dictate which headers can sanely
include which others ... but that's a big task for another day.

storage/proc.h should not include replication/syncrep.h, especially not
when the latter includes storage/proc.h; but in any case this was a pretty
poor thing from a modular layering standpoint.

file.

Per suggestion from Alvaro.