Alexander Korotkov, heavily revised by me.

Report and diagnosis by Peter Eisentraut.

Backpatch to 9.0.X.

be empty.  Because of binary migration usage, it might not be empty.

Peter Eisentraut's recent patch to allow host names in pg_hba.conf
changed the contents of pg_hba.conf.sample

Fujii Masao

The GIN code has absolutely no business exporting GIN-specific functions
with names as generic as compareItemPointers() or newScanKey(); that's
just trouble waiting to happen.  I got annoyed about this again just now
and decided to fix it.  This commit ensures that all global symbols
defined in access/gin/ have names including "gin" or "Gin".  There were a
couple of cases, like names involving "PostingItem", where arguably the
names were already sufficiently nongeneric; but I figured as long as I was
risking creating merge problems for unapplied GIN patches I might as well
impose a uniform policy.

I didn't touch any static symbol names.  There might be some places
where it'd be appropriate to rename some static functions to match
siblings that are exported, but I'll leave that for another time.

The better estimate requires more statistics than we previously stored:
in particular, counts of "entry" versus "data" pages within the index,
as well as knowledge of the number of distinct key values.  We collect
this information during initial index build and update it during VACUUM,
storing the info in new fields on the index metapage.  No initdb is
required because these fields will read as zeroes in a pre-existing
index, and the new gincostestimate code is coded to behave (reasonably)
sanely if they are zeroes.

Teodor Sigaev, reviewed by Jan Urbanski, Tom Lane, and Itagaki Takahiro.

Look only at the non-localized part of the output from "vcbuild /?",
which is used to determine the version of Visual Studio in use. Different
languages seem to localize different amounts of the string, but we assume
the part "Microsoft Visual C++" won't be modified.

a corresponding "to" character.

Author: Josh Kupershmidt

This is not the hoped-for facility of using INSERT/UPDATE/DELETE inside
a WITH, but rather the other way around.  It seems useful in its own
right anyway.

Note: catversion bumped because, although the contents of stored rules
might look compatible, there's actually a subtle semantic change.
A single Query containing a WITH and INSERT...VALUES now represents
writing the WITH before the INSERT, not before the VALUES.  While it's
not clear that that matters to anyone, it seems like a good idea to
have it cited in the git history for catversion.h.

Original patch by Marko Tiikkaja, with updating and cleanup by
Hitoshi Harada.

Peter Eisentraut, reviewed by KaiGai Kohei and Tom Lane

I also rearranged the order of the sections to match the logical order
of processing steps: the distinct-elimination implied by SELECT DISTINCT
happens before, not after, any UNION/INTERSECT/EXCEPT combination.

Per a suggestion from Hitoshi Harada.

Author: Quan Zongliang
Documentation updates by David Fetter

Corrupt RADIUS responses were treated as errors and not ignored
(which the RFC2865 states they should be). This meant that a
user with unfiltered access to the network of the PostgreSQL
or RADIUS server could send a spoofed RADIUS response
to the PostgreSQL server causing it to reject a valid login,
provided the attacker could also guess (or brute-force) the
correct port number.

Fix is to simply retry the receive in a loop until the timeout
has expired or a valid (signed by the correct RADIUS server)
packet arrives.

Reported by Alan DeKok in bug #5687.

Error pointed out by Fujii Masao, though not his patch.

     * Microsoft reports it is related to mutex failure:
     *   http://archives.postgresql.org/pgsql-hackers/2010-09/msg00790.php

This patch eliminates the former need to sort the output of an Append scan
when an ordered scan of an inheritance tree is wanted.  This should be
particularly useful for fast-start cases such as queries with LIMIT.

Original patch by Greg Stark, with further hacking by Hans-Jurgen Schonig,
Robert Haas, and Tom Lane.

xgettext is only required when make init-po is run manually; it is not
required for a build.  The intent to handle that was already there, but
the ifdef's were in the wrong place.

This is a parsed DocBook DTD for the PSGML Emacs mode, but it hasn't
been updated since we switched to DocBook 4.2 about seven years ago.
Also, PSGML has deprecated this method of DTD parsing.

The GRANT reference page failed to mention that the USAGE privilege
allows modifying associated user mappings, although this was already
documented on the CREATE/ALTER/DROP USER MAPPING pages.

Brendan Jurd

A tidy up for recently committed changes to startup latch.

Fujii Masao

Fujii Masao

ecpglib. Instead of parsing the statement just as ask the database server. This
patch removes the whole client side track keeping of the current transaction
status.

to see if a particular privilege has been granted to PUBLIC.

The issue was reported by Jim Nasby.
Patch by Alvaro Herrera, and reviewed by KaiGai Kohei.

We may as well make pgstat_count_heap_scan() and related macros just count
whenever rel->pgstat_info isn't null.  Testing pgstat_track_counts buys
nothing at all in the normal case where that flag is ON; and when it's OFF,
the pgstat_info link will be null, so it's still a useless test.

This change is unlikely to buy any noticeable performance improvement,
but a cycle shaved is a cycle earned; and my investigations earlier today
convinced me that we're down to the point where individual instructions in
the inner execution loops are starting to matter.

This was broken in 9.0 while improving plpython's conversion behavior for
bytea and boolean.  Per bug report from maizi.

The original coding was quite sloppy about handling the case where
XLogReadBuffer fails (because the page has since been deleted).  This
would result in either "bad buffer id: 0" or an Assert failure during
replay, if indeed the page were no longer there.  In a couple of places
it also neglected to check whether the change had already been applied,
which would probably result in corrupted index contents.  I believe that
bug #5703 is an instance of the first problem.  These issues could show up
without replication, but only if you were unfortunate enough to crash
between modification of a GIN index and the next checkpoint.

Back-patch to 8.2, which is as far back as GIN has WAL support.

This patch merges the responsibility for NOT-flattening into
eval_const_expressions' processing.  It wasn't done that way originally
because prepqual.c is far older than eval_const_expressions.  But putting
this work into eval_const_expressions saves one pass over the qual trees,
and in fact saves even more than that because we can exploit the knowledge
that the subexpressions have already been recursively simplified.  Doing it
this way also lets us do it uniformly over all expressions, whereas
prepqual.c formerly just did it at top level to save cycles.  That should
improve the planner's ability to recognize logically-equivalent constructs.

While at it, also add the ability to fold a NOT into BooleanTest and
NullTest constructs (the latter only for the scalar-datatype case).

Per discussion of bug #5702.