Report success when Windows kill() emulation signals an exiting process.

This is consistent with the POSIX verdict that kill() shall not report
ESRCH for a zombie process.  Back-patch to 9.0 (all supported versions).
Test code from commit d7cdf6ee36adeac9233678fb8f2a112e6678a770 depends
on it, and log messages about kill() reporting "Invalid argument" will
cease to appear for this not-unexpected condition.

MSVC: Substitute $(top_builddir) in REGRESS_OPTS.

Commit d7cdf6ee36adeac9233678fb8f2a112e6678a770 introduced a usage
thereof.  Back-patch to 9.0, like that commit.

Re-enable error for "SELECT ... OFFSET -1".

The executor has thrown errors for negative OFFSET values since 8.4 (see
commit bfce56eea45b1369b7bb2150a150d1ac109f5073), but in a moment of brain
fade I taught the planner that OFFSET with a constant negative value was a
no-op (commit 1a1832eb085e5bca198735e5d0e766a3cb61b8fc).  Reinstate the
former behavior by only discarding OFFSET with a value of exactly 0.  In
passing, adjust a planner comment that referenced the ancient behavior.

Back-patch to 9.3 where the mistake was introduced.

Check block number against the correct fork in get_raw_page().

get_raw_page tried to validate the supplied block number against
RelationGetNumberOfBlocks(), which of course is only right when
accessing the main fork.  In most cases, the main fork is longer
than the others, so that the check was too weak (allowing a
lower-level error to be reported, but no real harm to be done).
However, very small tables could have an FSM larger than their heap,
in which case the mistake prevented access to some FSM pages.
Per report from Torsten Foertsch.

In passing, make the bad-block-number error into an ereport not elog
(since it's certainly not an internal error); and fix sloppily
maintained comment for RelationGetNumberOfBlocksInFork.

This has been wrong since we invented relation forks, so back-patch
to all supported branches.

Allow empty string object keys in json_object().

This makes the behaviour consistent with the json parser, other
json-generating functions, and the JSON standards.

Diagnose incompatible OpenLDAP versions during build and test.

With OpenLDAP versions 2.4.24 through 2.4.31, inclusive, PostgreSQL
backends can crash at exit.  Raise a warning during "configure" based on
the compile-time OpenLDAP version number, and test the crash scenario in
the dblink test suite.  Back-patch to 9.0 (all supported versions).

Unset some local environment variables in TAP tests

Unset environment variables that control message language, so that we
can compare some program output with expected strings.  This is very
similar to what pg_regress does.

gitattributes: Ignore time zone data files for whitespace checks

The latest update introduced some funny whitespace, but since they are
externally maintained files, we add them to the list of files to ignore.

Reject out-of-range numeric timezone specifications.

In commit 631dc390f49909a5c8ebd6002cfb2bcee5415a9d, we started to handle
simple numeric timezone offsets via the zic library instead of the old
CTimeZone/HasCTZSet kluge.  However, we overlooked the fact that the zic
code will reject UTC offsets exceeding a week (which seems a bit arbitrary,
but not because it's too tight ...).  This led to possibly setting
session_timezone to NULL, which results in crashes in most timezone-related
operations as of 9.4, and crashes in a small number of places even before
that.  So check for NULL return from pg_tzset_offset() and report an
appropriate error message.  Per bug #11014 from Duncan Gillis.

Back-patch to all supported branches, like the previous patch.
(Unfortunately, as of today that no longer includes 8.4.)

Release notes for 9.3.5, 9.2.9, 9.1.14, 9.0.18, 8.4.22.

Adjust cutoff points in newly-added sanity tests.

Per recommendation from Andres.

Defend against bad relfrozenxid/relminmxid/datfrozenxid/datminmxid values.

In commit a61daa14d56867e90dc011bbba52ef771cea6770, we fixed pg_upgrade so
that it would install sane relminmxid and datminmxid values, but that does
not cure the problem for installations that were already pg_upgraded to
9.3; they'll initially have "1" in those fields.  This is not a big problem
so long as 1 is "in the past" compared to the current nextMultiXact
counter.  But if an installation were more than halfway to the MXID wrap
point at the time of upgrade, 1 would appear to be "in the future" and
that would effectively disable tracking of oldest MXIDs in those
tables/databases, until such time as the counter wrapped around.

While in itself this isn't worse than the situation pre-9.3, where we did
not manage MXID wraparound risk at all, the consequences of premature
truncation of pg_multixact are worse now; so we ought to make some effort
to cope with this.  We discussed advising users to fix the tracking values
manually, but that seems both very tedious and very error-prone.

Instead, this patch adopts two amelioration rules.  First, a relminmxid
value that is "in the future" is allowed to be overwritten with a
full-table VACUUM's actual freeze cutoff, ignoring the normal rule that
relminmxid should never go backwards.  (This essentially assumes that we
have enough defenses in place that wraparound can never occur anymore,
and thus that a value "in the future" must be corrupt.)  Second, if we see
any "in the future" values then we refrain from truncating pg_clog and
pg_multixact.  This prevents loss of clog data until we have cleaned up
all the broken tracking data.  In the worst case that could result in
considerable clog bloat, but in practice we expect that relfrozenxid-driven
freezing will happen soon enough to fix the problem before clog bloat
becomes intolerable.  (Users could do manual VACUUM FREEZEs if not.)

Note that this mechanism cannot save us if there are already-wrapped or
already-truncated-away MXIDs in the table; it's only capable of dealing
with corrupt tracking values.  But that's the situation we have with the
pg_upgrade bug.

For consistency, apply the same rules to relfrozenxid/datfrozenxid.  There
are not known mechanisms for these to get messed up, but if they were, the
same tactics seem appropriate for fixing them.

Properly use DEFAULT_EVENT_SOURCE in pgevent.c

This was broken and reverted in a previous commit. The (this time verified)
fix is to simly add postgres_fe.h.

MauMau, review by Amit Kapila

Translation updates

Update SQL features list

Replace "internationalize" with "localize" where appropriate

First-draft release notes for 9.3.5.

As usual, the release notes for older branches will be made by cutting
these down, but put them up for community review first.

Note: a few of these items actually don't apply to 9.3, but only to older
branches.  I'll sort that out when copying the text into the older
release-X.Y.sgml files.

Fix xreflabel for hot_standby_feedback.

Rather remarkable that this has been wrong since 9.1 and nobody noticed.

Update time zone data files to tzdata release 2014e.

DST law changes in Crimea, Egypt, Morocco.  New zone Antarctica/Troll
for Norwegian base in Queen Maud Land.

Partial fix for dropped columns in functions returning composite.

When a view has a function-returning-composite in FROM, and there are
some dropped columns in the underlying composite type, ruleutils.c
printed junk in the column alias list for the reconstructed FROM entry.
Before 9.3, this was prevented by doing get_rte_attribute_is_dropped
tests while printing the column alias list; but that solution is not
currently available to us for reasons I'll explain below.  Instead,
check for empty-string entries in the alias list, which can only exist
if that column position had been dropped at the time the view was made.
(The parser fills in empty strings to preserve the invariant that the
aliases correspond to physical column positions.)

While this is sufficient to handle the case of columns dropped before
the view was made, we have still got issues with columns dropped after
the view was made.  In particular, the view could contain Vars that
explicitly reference such columns!  The dependency machinery really
ought to refuse the column drop attempt in such cases, as it would do
when trying to drop a table column that's explicitly referenced in
views.  However, we currently neglect to store dependencies on columns
of composite types, and fixing that is likely to be too big to be
back-patchable (not to mention that existing views in existing databases
would not have the needed pg_depend entries anyway).  So I'll leave that
for a separate patch.

Pre-9.3, ruleutils would print such Vars normally (with their original
column names) even though it suppressed their entries in the RTE's
column alias list.  This is certainly bogus, since the printed view
definition would fail to reload, but at least it didn't crash.  However,
as of 9.3 the printed column alias list is tightly tied to the names
printed for Vars; so we can't treat columns as dropped for one purpose
and not dropped for the other.  This is why we can't just put back the
get_rte_attribute_is_dropped test: it results in an assertion failure
if the view in fact contains any Vars referencing the dropped column.
Once we've got dependencies preventing such cases, we'll probably want
to do it that way instead of relying on the empty-string test used here.

This fix turned up a very ancient bug in outfuncs/readfuncs, namely
that T_String nodes containing empty strings were not dumped/reloaded
correctly: the node was printed as "<>" which is read as a string
value of <>.  Since (per SQL) we disallow empty-string identifiers,
such nodes don't occur normally, which is why we'd not noticed.
(Such nodes aren't used for literal constants, just identifiers.)

Per report from Marc Schablewski.  Back-patch to 9.3 which is where
the rule printing behavior changed.  The dangling-variable case is
broken all the way back, but that's not what his complaint is about.

Limit pg_upgrade authentication advice to always-secure techniques.

~/.pgpass is a sound choice everywhere, and "peer" authentication is
safe on every platform it supports.  Cease to recommend "trust"
authentication, the safety of which is deeply configuration-specific.
Back-patch to 9.0, where pg_upgrade was introduced.

Fix two low-probability memory leaks in regular expression parsing.

If pg_regcomp failed after having invoked markst/cleanst, it would leak any
"struct subre" nodes it had created.  (We've already detected all regex
syntax errors at that point, so the only likely causes of later failure
would be query cancel or out-of-memory.)  To fix, make sure freesrnode
knows the difference between the pre-cleanst and post-cleanst cleanup
procedures.  Add some documentation of this less-than-obvious point.

Also, newlacon did the wrong thing with an out-of-memory failure from
realloc(), so that the previously allocated array would be leaked.

Both of these are pretty low-probability scenarios, but a bug is a bug,
so patch all the way back.

Per bug #10976 from Arthur O'Dwyer.

Revert broken change to pgevent.c

pgevent doesn't include the global PostgreSQL headers, for a reason,
and therefor cannot rely on defines in it...

Add option to pg_ctl to choose event source for logging

pg_ctl will log to the Windows event log when it is running as a service,
which is the primary way of running PostgreSQL on Windows. This option
makes it possible to specify which event source to use for this, in order
to separate different instances. The server logging itself is still controlled
by the regular logging parameters, including a separate setting for the event
source. The parameter to pg_ctl only controlls the logging from pg_ctl itself.

MauMau, review in many iterations by Amit Kapila and me.

doc: Spell checking

Fix bugs in SP-GiST search with range type's -|- (adjacent) operator.

The consistent function contained several bugs:

* The "if (which2) { ... }"  block was broken. It compared the  argument's
lower bound against centroid's upper bound, while it was supposed to compare
the argument's upper bound against the centroid's lower bound (the comment
was correct, code was wrong). Also, it cleared bits in the "which1"
variable, while it was supposed to clear bits in "which2".

* If the argument's upper bound was equal to the centroid's lower bound, we
descended to both halves (= all quadrants). That's unnecessary, searching
the right quadrants is sufficient. This didn't lead to incorrect query
results, but was clearly wrong, and slowed down queries unnecessarily.

* In the case that argument's lower bound is adjacent to the centroid's
upper bound, we also don't need to visit all quadrants. Per similar
reasoning as previous point.

* The code where we compare the previous centroid with the current centroid
should match the code where we compare the current centroid with the
argument. The point of that code is to redo the calculation done in the
previous level, to see if we were supposed to traverse left or right (or up
or down), and if we actually did. If we moved in the different direction,
then we know there are no matches for bound.

Refactor the code and adds comments to make it more readable and easier to
reason about.

Backpatch to 9.3 where SP-GiST support for range types was introduced.

Allow join removal in some cases involving a left join to a subquery.

We can remove a left join to a relation if the relation's output is
provably distinct for the columns involved in the join clause (considering
only equijoin clauses) and the relation supplies no variables needed above
the join.  Previously, the join removal logic could only prove distinctness
by reference to unique indexes of a table.  This patch extends the logic
to consider subquery relations, wherein distinctness might be proven by
reference to GROUP BY, DISTINCT, etc.

We actually already had some code to check that a subquery's output was
provably distinct, but it was hidden inside pathnode.c; which was a pretty
bad place for it really, since that file is mostly boilerplate Path
construction and comparison.  Move that code to analyzejoins.c, which is
arguably a more appropriate location, and is certainly the site of the
new usage for it.

David Rowley, reviewed by Simon Riggs

Move check for SSL_get_current_compression to run on mingw

Mingw uses a different header file than msvc, so we don't get the
hardcoded value, so we need the configure test to run.

doc: Put new options in right order on reference pages

pg_upgrade: Fix spacing in help output

pg_basebackup: Add more information about --max-rate option to help output

It was previously not clear what unit the option argument should have.

json_build_object and json_build_array are stable, not immutable.

These functions indirectly invoke output functions, so they can't be
immutable.

Backpatch to 9.4 where they were introduced.

Catalog version bumped.

Add missing doc changes for ee80f043bc9b

Per note from Tom Lane

Fix REASSIGN OWNED for text search objects

Trying to reassign objects owned by a user that had text search
dictionaries or configurations used to fail with:
ERROR:  unexpected classid 3600
or
ERROR:  unexpected classid 3602

Fix by adding cases for those object types in a switch in pg_shdepend.c.

Both REASSIGN OWNED and text search objects go back all the way to 8.1,
so backpatch to all supported branches.  In 9.3 the alter-owner code was
made generic, so the required change in recent branches is pretty
simple; however, for 9.2 and older ones we need some additional
reshuffling to enable specifying objects by OID rather than name.

Text search templates and parsers are not owned objects, so there's no
change required for them.

Per bug #9749 reported by Michal Novotný

Detect presence of SSL_get_current_compression

Apparently we still build against OpenSSL so old that it doesn't
have this function, so add an autoconf check for it to make the
buildfarm happy. If the function doesn't exist, always return
that compression is disabled, since presumably the actual
compression functionality is always missing.

For now, hardcode the function as present on MSVC, since we should
hopefully be well beyond those old versions on that platform.

Add missing source files to nls.mk

These are files under common/ that have been moved around.  Updating
these manually is not satisfactory, but it's the only solution at the
moment.

Include SSL compression status in psql banner and connection logging

Both the psql banner and the connection logging already included
SSL status, cipher and bitlength, this adds the information about
compression being on or off.

Small spelling fix

Add missing serial commas

Also update one place where the wal_level "logical" was not added to an
error message.

Remove dependency on wsock32.lib in favor of ws2_32

ws2_32 is the new version of the library that should be used, as
it contains the require functionality from wsock32 as well as some
more (which is why some binaries were already using ws2_32).

Michael Paquier, reviewed by MauMau

doc: small fixes for REINDEX reference page

From: Josh Kupershmidt <schmiddy@gmail.com>

psql: Show tablespace size in \db+

Fabrízio de Royes Mello

Move view reloptions into their own varlena struct

Per discussion after a gripe from me in
http://www.postgresql.org/message-id/20140611194633.GH18688@eldon.alvh.no-ip.org

Jaime Casanova

Add file version information to most installed Windows binaries.

Prominent binaries already had this metadata.  A handful of minor
binaries, such as pg_regress.exe, still lack it; efforts to eliminate
such exceptions are welcome.

Michael Paquier, reviewed by MauMau.

contrib/test_decoding/Makefile sets MODULES, so omit OBJS.

Michael Paquier

MSVC: Apply icons to all binaries having them in a MinGW build.

MSVC: Process Makefile line continuations more like "make" does.

Unlike "make" itself, the MSVC build process recognized a continuation
even with whitespace after the backslash.  (Due to a typo, some code
sites accepted the letter "s" instead of whitespace).  Also, it would
consume any number of newlines following a single backslash.  This is
mere cleanup; those behaviors were unlikely to cause bugs.

MSVC: Recognize PGFILEDESC in contrib and conversion_procs modules.

Achieve this by consistently using four-argument Solution::AddProject()
calls.  Remove ad hoc Makefile parsing made redundant by doing that.

Michael Paquier and Noah Misch, reviewed by MauMau.

Fix warnings added in 8d9a0e85bd6ab4fe5268a1d759a787f72ff9333e.

Prevent bitmap heap scans from showing unnecessary block info in EXPLAIN ANALYZE.

EXPLAIN ANALYZE shows the information of the numbers of exact/lossy blocks which
bitmap heap scan processes. But, previously, when those numbers were both zero,
it displayed only the prefix "Heap Blocks:" in TEXT output format. This is strange
and would confuse the users. So this commit suppresses such unnecessary information.

Backpatch to 9.4 where EXPLAIN ANALYZE was changed so that such information was
displayed.

Etsuro Fujita

Remove incorrect comment from postgres_fdw.c.

Etsuro Fujita

Support --with-extra-version equivalent functionality in MSVC build

Adds a configuration parameter, extraver, that is appended to the
version number when built.

Michael Paquier, reviewed by Muhammad Asif Naeem

Minimal psql tab completion support for SET search_path.

Complete SET search_path = ... to non-temporary and non-toast
schemas. Since there pretty much is no use case to add those to the
search path and there can be many it's helpful to exclude them.

It'd be nicer to complete multiple search path elements, but that's
not easy.

Jeff Janes

Fix decoding of consecutive MULTI_INSERTs emitted by one heap_multi_insert().

Commit 1b86c81d2d fixed the decoding of toasted columns for the rows
contained in one xl_heap_multi_insert record. But that's not actually
enough, because heap_multi_insert() will actually first toast all
passed in rows and then emit several *_multi_insert records; one for
each page it fills with tuples.

Add a XLOG_HEAP_LAST_MULTI_INSERT flag which is set in
xl_heap_multi_insert->flag denoting that this multi_insert record is
the last emitted by one heap_multi_insert() call. Then use that flag
in decode.c to only set clear_toast_afterwards in the right situation.

Expand the number of rows inserted via COPY in the corresponding
regression test to make sure that more than one heap page is filled
with tuples by one heap_multi_insert() call.

Backpatch to 9.4 like the previous commit.

Add autocompletion of locale keywords for CREATE DATABASE

Adds support for autocomplete of LC_COLLATE and LC_CTYPE to
the CREATE DATABASE command in psql.

Fix bug with whole-row references to append subplans.

ExecEvalWholeRowVar incorrectly supposed that it could "bless" the source
TupleTableSlot just once per query.  But if the input is coming from an
Append (or, perhaps, other cases?) more than one slot might be returned
over the query run.  This led to "record type has not been registered"
errors when a composite datum was extracted from a non-blessed slot.

This bug has been there a long time; I guess it escaped notice because when
dealing with subqueries the planner tends to expand whole-row Vars into
RowExprs, which don't have the same problem.  It is possible to trigger
the problem in all active branches, though, as illustrated by the added
regression test.

Fix whitespace

Implement IMPORT FOREIGN SCHEMA.

This command provides an automated way to create foreign table definitions
that match remote tables, thereby reducing tedium and chances for error.
In this patch, we provide the necessary core-server infrastructure and
implement the feature fully in the postgres_fdw foreign-data wrapper.
Other wrappers will throw a "feature not supported" error until/unless
they are updated.

Ronan Dunklau and Michael Paquier, additional work by me

Adjust blank lines around PG_MODULE_MAGIC defines, for consistency

Report by Robert Haas

Add new ECHO mode 'errors' that displays only failed commands in psql.

When the psql variable ECHO is set to 'erros', only failed SQL commands
are printed to standard error output. Also this patch adds -b option into psql.
This is equivalent to setting the variable ECHO to 'errors'.

Pavel Stehule, reviewed by Fabrízio de Royes Mello, Samrat Revagade,
Kumar Rajeev Rastogi, Abhijit Menon-Sen, and me.

Fix error hint style.

Mistake caught by Tom Lane.

Improve error messages for bytea decoding failures.

Craig Ringer

Fix whitespace

Update key words table for 9.4

doc: Link text to table by id

Don't assume a subquery's output is unique if there's a SRF in its tlist.

While the x output of "select x from t group by x" can be presumed unique,
this does not hold for "select x, generate_series(1,10) from t group by x",
because we may expand the set-returning function after the grouping step.
(Perhaps that should be re-thought; but considering all the other oddities
involved with SRFs in targetlists, it seems unlikely we'll change it.)
Put a check in query_is_distinct_for() so it's not fooled by such cases.

Back-patch to all supported branches.

David Rowley

doc: Fix spacing in verbatim environments

Fix typo in comment.

This typo was accidentally added by recent commit 4cbd128.

In pg_dump, show server and pg_dump versions with or without --verbose.

We used to print this information only in verbose mode, but it's argued
that it's useful enough to print always; one reason being that this
provides some documentation about which Postgres versions the dump is
meant to reload into.

Jing Wang, reviewed by Jeevan Chalke

pg_upgrade: allow upgrades for new-only TOAST tables

Previously, when calculations on the need for toast tables changed,
pg_upgrade could not handle cases where the new cluster needed a TOAST
table and the old cluster did not.  (It already handled the opposite
case.)  This fixes the "OID mismatch" error typically generated in this
case.

Backpatch through 9.2

Fix typos in comments.

Remove swpb-based spinlock implementation for ARMv5 and earlier.

Per recent analysis by Andres Freund, this implementation is in fact
unsafe, because ARMv5 has weak memory ordering, which means tha the
CPU could move loads or stores across the volatile store performed by
the default S_UNLOCK.  We could try to fix this, but have no ARMv5
hardware to test on, so removing support seems better.  We can still
support ARMv5 systems on GCC versions new enough to have built-in
atomics support for this platform, and can also re-add support for
the old way if someone has hardware that can be used to test a fix.
However, since the requirement to use a relatively-new GCC hasn't
been an issue for ARMv6 or ARMv7, which lack the swpb instruction
altogether, perhaps it won't be an issue for ARMv5 either.

Fix decoding of MULTI_INSERTs when rows other than the last are toasted.

When decoding the results of a HEAP2_MULTI_INSERT (currently only
generated by COPY FROM) toast columns for all but the last tuple
weren't replaced by their actual contents before being handed to the
output plugin. The reassembled toast datums where disregarded after
every REORDER_BUFFER_CHANGE_(INSERT|UPDATE|DELETE) which is correct
for plain inserts, updates, deletes, but not multi inserts - there we
generate several REORDER_BUFFER_CHANGE_INSERTs for a single
xl_heap_multi_insert record.

To solve the problem add a clear_toast_afterwards boolean to
ReorderBufferChange's union member that's used by modifications. All
row changes but multi_inserts always set that to true, but
multi_insert sets it only for the last change generated.

Add a regression test covering decoding of multi_inserts - there was
none at all before.

Backpatch to 9.4 where logical decoding was introduced.

Bug found by Petr Jelinek.

Consistently pass an "unsigned char" to ctype.h functions.

The isxdigit() calls relied on undefined behavior.  The isascii() call
was well-defined, but our prevailing style is to include the cast.
Back-patch to 9.4, where the isxdigit() calls were introduced.

Remove dead typeStruct variable from plpy_spi.c.

Left behind by 8b6010b8350a1756cd85595705971df81b5ffc07.

Fix double-free bug of WAL streaming buffer in pg_receivexlog.

This bug was introduced while refactoring in commit 74cbe96.

Refactor pg_receivexlog main loop code, for readability.

Previously the source codes for receiving the data and for
polling the socket were included in pg_receivexlog main loop.
This commit splits out them as separate functions. This is
useful for improving the readability of main loop code and
making the future pg_receivexlog-related patch simpler.

Split out the description of page-level lock as new subsection in document.

Michael Banck

Don't cache per-group context across the whole query in orderedsetaggs.c.

Although nodeAgg.c currently uses the same per-group memory context for
all groups of a query, that might change in future.  Avoid assuming it.
This costs us an extra AggCheckCallContext() call per group, but that's
pretty cheap and is probably good from a safety standpoint anyway.

Back-patch to 9.4 in case any third-party code copies this logic.

Andrew Gierth

Redesign API presented by nodeAgg.c for ordered-set and similar aggregates.

The previous design exposed the input and output ExprContexts of the
Agg plan node, but work on grouping sets has suggested that we'll regret
doing that.  Instead provide more narrowly-defined APIs that can be
implemented in multiple ways, namely a way to get a short-term memory
context and a way to register an aggregate shutdown callback.

Back-patch to 9.4 where the bad APIs were introduced, since we don't
want third-party code using these APIs and then having to change in 9.5.

Andrew Gierth

Improve support for composite types in PL/Python.

Allow PL/Python functions to return arrays of composite types.
Also, fix the restriction that plpy.prepare/plpy.execute couldn't
handle query parameters or result columns of composite types.

In passing, adopt a saner arrangement for where to release the
tupledesc reference counts acquired via lookup_rowtype_tupdesc.
The callers of PLyObject_ToCompositeDatum were doing the lookups,
but then the releases happened somewhere down inside subroutines
of PLyObject_ToCompositeDatum, which is bizarre and bug-prone.
Instead release in the same function that acquires the refcount.

Ed Behn and Ronan Dunklau, reviewed by Abhijit Menon-Sen

Use a separate temporary directory for the Unix-domain socket

Creating the Unix-domain socket in the build directory can run into
name-length limitations.  Therefore, create the socket file in the
default temporary directory of the operating system.  Keep the temporary
data directory etc. in the build tree.

Support vpath builds in TAP tests

Smooth reporting of commit/rollback statistics.

If a connection committed or rolled back any transactions within a
PGSTAT_STAT_INTERVAL pacing interval without accessing any tables,
the reporting of those statistics would be held up until the
connection closed or until it ended a PGSTAT_STAT_INTERVAL interval
in which it had accessed a table.  This could result in under-
reporting of transactions for an extended period, followed by a
spike in reported transactions.

While this is arguably a bug, the impact is minimal, primarily
affecting, and being affected by, monitoring software.  It might
cause more confusion than benefit to change the existing behavior
in released stable branches, so apply only to master and the 9.4
beta.

Gurjeet Singh, with review and editing by Kevin Grittner,
incorporating suggested changes from Abhijit Menon-Sen and Tom
Lane.

pg_upgrade:  preserve database and relation minmxid values

Also set these values for pre-9.3 old clusters that don't have values to
preserve.

Analysis by Alvaro

Backpatch through 9.3

Rename logical decoding's pg_llog directory to pg_logical.

The old name wasn't very descriptive as of actual contents of the
directory, which are historical snapshots in the snapshots/
subdirectory and mappingdata for rewritten tuples in
mappings/. There's been a fair amount of discussion what would be a
good name. I'm settling for pg_logical because it's likely that
further data around logical decoding and replication will need saving
in the future.

Also add the missing entry for the directory into storage.sgml's list
of PGDATA contents.

Bumps catversion as the data directories won't be compatible.

pg_upgrade:  no need to remove "members" files for pre-9.3 upgrades

Per analysis by Alvaro

Backpatch through 9.3

Add some errdetail to checkRuleResultList().

This function wasn't originally thought to be really user-facing,
because converting a table to a view isn't something we expect people
to do manually.  So not all that much effort was spent on the error
messages; in particular, while the code will complain that you got
the column types wrong it won't say exactly what they are.  But since
we repurposed the code to also check compatibility of rule RETURNING
lists, it's definitely user-facing.  It now seems worthwhile to add
errdetail messages showing exactly what the conflict is when there's
a mismatch of column names or types.  This is prompted by bug #10836
from Matthias Raffelsieper, which might have been forestalled if the
error message had reported the wrong column type as being "record".

Back-patch to 9.4, but not into older branches where the set of
translatable error strings is supposed to be stable.

Prevent psql from issuing BEGIN before ALTER SYSTEM when AUTOCOMMIT is off.

The autocommit-off mode works by issuing an implicit BEGIN just before
any command that is not already in a transaction block and is not itself
a BEGIN or other transaction-control command, nor a command that
cannot be executed inside a transaction block. This commit prevents psql
from issuing such an implicit BEGIN before ALTER SYSTEM because it's
not allowed inside a transaction block.

Backpatch to 9.4 where ALTER SYSTEM was added.

Report by Feike Steenbergen

Allow CREATE/ALTER DATABASE to manipulate datistemplate and datallowconn.

Historically these database properties could be manipulated only by
manually updating pg_database, which is error-prone and only possible for
superusers.  But there seems no good reason not to allow database owners to
set them for their databases, so invent CREATE/ALTER DATABASE options to do
that.  Adjust a couple of places that were doing it the hard way to use the
commands instead.

Vik Fearing, reviewed by Pavel Stehule

Refactor CREATE/ALTER DATABASE syntax so options need not be keywords.

Most of the existing option names are keywords anyway, but we can get rid
of LC_COLLATE and LC_CTYPE as keywords known to the lexer/grammar.  This
immediately reduces the size of the grammar tables by about 8KB, and will
save more when we add additional CREATE/ALTER DATABASE options in future.

A side effect of the implementation is that the CONNECTION LIMIT option
can now also be spelled CONNECTION_LIMIT.  We choose not to document this,
however.

Vik Fearing, based on a suggestion by me; reviewed by Pavel Stehule

Remove some useless code in the configure script.

Almost ten years ago, commit e48322a6d6cfce1ec52ab303441df329ddbc04d1 broke
the logic in ACX_PTHREAD by looping through all the possible flags rather
than stopping with the first one that would work.  This meant that
$acx_pthread_ok was no longer meaningful after the loop; it would usually
be "no", whether or not we'd found working thread flags.  The reason nobody
noticed is that Postgres doesn't actually use any of the symbols set up
by the code after the loop.  Rather than complicate things some more to
make it work as designed, let's just remove all that dead code, and thereby
save a few cycles in each configure run.

Improve handling of OOM score adjustment in sample Linux start script.

Per a suggestion from Christoph Berg.

Fix inadequately-sized output buffer in contrib/unaccent.

The output buffer size in unaccent_lexize() was calculated as input string
length times pg_database_encoding_max_length(), which effectively assumes
that replacement strings aren't more than one character.  While that was
all that we previously documented it to support, the code actually has
always allowed replacement strings of arbitrary length; so if you tried
to make use of longer strings, you were at risk of buffer overrun.  To fix,
use an expansible StringInfo buffer instead of trying to determine the
maximum space needed a-priori.

This would be a security issue if unaccent rules files could be installed
by unprivileged users; but fortunately they can't, so in the back branches
the problem can be labeled as improper configuration by a superuser.
Nonetheless, a memory stomp isn't a nice way of reacting to improper
configuration, so let's back-patch the fix.

Avoid copying index tuples when building an index.

The previous code, perhaps out of concern for avoid memory leaks, formed
the tuple in one memory context and then copied it to another memory
context.  However, this doesn't appear to be necessary, since
index_form_tuple and the functions it calls take precautions against
leaking memory.  In my testing, building the tuple directly inside the
sort context shaves several percent off the index build time.
Rearrange things so we do that.

Patch by me.  Review by Amit Kapila, Tom Lane, Andres Freund.

Issue a WARNING about invalid rule file format in contrib/unaccent.

We were already issuing a WARNING, albeit only elog not ereport, for
duplicate source strings; so warning rather than just being stoically
silent seems like the best thing to do here.  Arguably both of these
complaints should be upgraded to ERRORs, but that might be more
behavioral change than people want.

Note: the faulty line is already printed via an errcontext hook,
so there's no need for more information than these messages provide.

Allow multi-character source strings in contrib/unaccent.

This could be useful in languages where diacritic signs are represented as
separate characters; more generally it supports using unaccent dictionaries
for substring substitutions beyond narrowly conceived "diacritic removal".
In any case, since the rule-file parser doesn't complain about
multi-character source strings, it behooves us to do something unsurprising
with them.

Allow empty replacement strings in contrib/unaccent.

This is useful in languages where diacritic signs are represented as
separate characters; it's also one step towards letting unaccent be used
for arbitrary substring substitutions.

In passing, improve the user documentation for unaccent, which was sadly
vague about some important details.

Mohammad Alhashash, reviewed by Abhijit Menon-Sen

pg_upgrade:  update C comments about pg_dumpall

There were some C comments that hadn't been updated from the switch of
using only pg_dumpall to using pg_dump and pg_dumpall, so update them.
Also, don't bother using --schema-only for pg_dumpall --globals-only.

Backpatch through 9.4

Don't prematurely free the BufferAccessStrategy in pgstat_heap().

This function continued to use it after heap_endscan() freed it.  In
passing, don't explicit create a strategy here.  Instead, use the one
created by heap_beginscan_strat(), if any.  Back-patch to 9.2, where use
of a BufferAccessStrategy here was introduced.