PostgreSQL 9.0.16 commit log

Stamp 9.0.16.

commit   : de02167f6305804ad9ab72296a2b612a4fc58e36    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2014 14:42:21 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2014 14:42:21 -0500    

Click here for diff

M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32
M src/interfaces/libpq/libpq.rc.in
M src/port/win32ver.rc

Last-minute updates for release notes.

commit   : 8f979e789347d3dec15d020945a7c6e1b416f759    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2014 14:25:49 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2014 14:25:49 -0500    

Click here for diff

Add entries for security issues.  
  
Security: CVE-2014-0060 through CVE-2014-0067  

M doc/src/sgml/release-8.4.sgml
M doc/src/sgml/release-9.0.sgml

Document risks of "make check" in the regression testing instructions.

commit   : 369c229d2f35e584175e34b9ce9cabf28284eb16    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2014 11:24:48 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2014 11:24:48 -0500    

Click here for diff

Since the temporary server started by "make check" uses "trust"  
authentication, another user on the same machine could connect to it  
as database superuser, and then potentially exploit the privileges of  
the operating-system user who started the tests.  We should change  
the testing procedures to prevent this risk; but discussion is required  
about the best way to do that, as well as more testing than is practical  
for an undisclosed security problem.  Besides, the same issue probably  
affects some user-written test harnesses.  So for the moment, we'll just  
warn people against using "make check" when there are untrusted users on  
the same machine.  
  
In passing, remove some ancient advice that suggested making the  
regression testing subtree world-writable if you'd built as root.  
That looks dangerously insecure in modern contexts, and anyway we  
should not be encouraging people to build Postgres as root.  
  
Security: CVE-2014-0067  

M doc/src/sgml/regress.sgml

Prevent potential overruns of fixed-size buffers.

commit   : 45bf2404a2f586a35e8647890a7d5917b787a623    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2014 11:20:35 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2014 11:20:35 -0500    

Click here for diff

Coverity identified a number of places in which it couldn't prove that a  
string being copied into a fixed-size buffer would fit.  We believe that  
most, perhaps all of these are in fact safe, or are copying data that is  
coming from a trusted source so that any overrun is not really a security  
issue.  Nonetheless it seems prudent to forestall any risk by using  
strlcpy() and similar functions.  
  
Fixes by Peter Eisentraut and Jozef Mlich based on Coverity reports.  
  
In addition, fix a potential null-pointer-dereference crash in  
contrib/chkpass.  The crypt(3) function is defined to return NULL on  
failure, but chkpass.c didn't check for that before using the result.  
The main practical case in which this could be an issue is if libc is  
configured to refuse to execute unapproved hashing algorithms (e.g.,  
"FIPS mode").  This ideally should've been a separate commit, but  
since it touches code adjacent to one of the buffer overrun changes,  
I included it in this commit to avoid last-minute merge issues.  
This issue was reported by Honza Horak.  
  
Security: CVE-2014-0065 for buffer overruns, CVE-2014-0066 for crypt()  

M contrib/chkpass/chkpass.c
M contrib/pg_standby/pg_standby.c
M src/backend/access/transam/xlog.c
M src/backend/tsearch/spell.c
M src/backend/utils/adt/datetime.c
M src/bin/initdb/initdb.c
M src/interfaces/ecpg/preproc/pgc.l
M src/interfaces/libpq/fe-protocol2.c
M src/interfaces/libpq/fe-protocol3.c
M src/port/exec.c
M src/test/regress/pg_regress.c
M src/timezone/pgtz.c

Predict integer overflow to avoid buffer overruns.

commit   : 2c3203e18551343db11ed9d372cd2a25d65d3f35    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 17 Feb 2014 09:33:31 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 17 Feb 2014 09:33:31 -0500    

Click here for diff

Several functions, mostly type input functions, calculated an allocation  
size such that the calculation wrapped to a small positive value when  
arguments implied a sufficiently-large requirement.  Writes past the end  
of the inadvertent small allocation followed shortly thereafter.  
Coverity identified the path_in() vulnerability; code inspection led to  
the rest.  In passing, add check_stack_depth() to prevent stack overflow  
in related functions.  
  
Back-patch to 8.4 (all supported versions).  The non-comment hstore  
changes touch code that did not exist in 8.4, so that part stops at 9.0.  
  
Noah Misch and Heikki Linnakangas, reviewed by Tom Lane.  
  
Security: CVE-2014-0064  

M contrib/hstore/hstore.h
M contrib/hstore/hstore_io.c
M contrib/hstore/hstore_op.c
M contrib/intarray/_int.h
M contrib/intarray/_int_bool.c
M contrib/ltree/ltree.h
M contrib/ltree/ltree_io.c
M contrib/ltree/ltxtquery_io.c
M src/backend/utils/adt/geo_ops.c
M src/backend/utils/adt/tsquery.c
M src/backend/utils/adt/tsquery_util.c
M src/backend/utils/adt/txid.c
M src/backend/utils/adt/varbit.c
M src/include/tsearch/ts_type.h
M src/include/utils/varbit.h

Fix handling of wide datetime input/output.

commit   : b9c3bb1b320afadbf292c408d213b48b1655072c    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 17 Feb 2014 09:33:31 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 17 Feb 2014 09:33:31 -0500    

Click here for diff

Many server functions use the MAXDATELEN constant to size a buffer for  
parsing or displaying a datetime value.  It was much too small for the  
longest possible interval output and slightly too small for certain  
valid timestamp input, particularly input with a long timezone name.  
The long input was rejected needlessly; the long output caused  
interval_out() to overrun its buffer.  ECPG's pgtypes library has a copy  
of the vulnerable functions, which bore the same vulnerabilities along  
with some of its own.  In contrast to the server, certain long inputs  
caused stack overflow rather than failing cleanly.  Back-patch to 8.4  
(all supported versions).  
  
Reported by Daniel Schüssler, reviewed by Tom Lane.  
  
Security: CVE-2014-0063  

M src/include/utils/datetime.h
M src/interfaces/ecpg/pgtypeslib/datetime.c
M src/interfaces/ecpg/pgtypeslib/dt.h
M src/interfaces/ecpg/pgtypeslib/dt_common.c
M src/interfaces/ecpg/pgtypeslib/interval.c
M src/interfaces/ecpg/pgtypeslib/timestamp.c
M src/interfaces/ecpg/test/expected/pgtypeslib-dt_test2.c
M src/interfaces/ecpg/test/expected/pgtypeslib-dt_test2.stdout
M src/interfaces/ecpg/test/pgtypeslib/dt_test2.pgc
M src/test/regress/expected/interval.out
M src/test/regress/sql/interval.sql

Avoid repeated name lookups during table and index DDL.

commit   : 43d4e965edf119b4f12df3e1488c82f32bfa9fe0    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 17 Feb 2014 09:33:31 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 17 Feb 2014 09:33:31 -0500    

Click here for diff

If the name lookups come to different conclusions due to concurrent  
activity, we might perform some parts of the DDL on a different table  
than other parts.  At least in the case of CREATE INDEX, this can be  
used to cause the permissions checks to be performed against a  
different table than the index creation, allowing for a privilege  
escalation attack.  
  
This changes the calling convention for DefineIndex, CreateTrigger,  
transformIndexStmt, transformAlterTableStmt, CheckIndexCompatible  
(in 9.2 and newer), and AlterTable (in 9.1 and older).  In addition,  
CheckRelationOwnership is removed in 9.2 and newer and the calling  
convention is changed in older branches.  A field has also been added  
to the Constraint node (FkConstraint in 8.4).  Third-party code calling  
these functions or using the Constraint node will require updating.  
  
Report by Andres Freund.  Patch by Robert Haas and Andres Freund,  
reviewed by Tom Lane.  
  
Security: CVE-2014-0062  

M src/backend/bootstrap/bootparse.y
M src/backend/catalog/index.c
M src/backend/catalog/pg_constraint.c
M src/backend/commands/alter.c
M src/backend/commands/indexcmds.c
M src/backend/commands/tablecmds.c
M src/backend/commands/trigger.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/equalfuncs.c
M src/backend/nodes/outfuncs.c
M src/backend/parser/parse_utilcmd.c
M src/backend/tcop/utility.c
M src/include/catalog/index.h
M src/include/catalog/pg_constraint.h
M src/include/commands/defrem.h
M src/include/commands/tablecmds.h
M src/include/commands/trigger.h
M src/include/nodes/parsenodes.h
M src/include/parser/parse_utilcmd.h
M src/include/tcop/utility.h

Document security implications of check_function_bodies.

commit   : 05514838ba7782c6719a0fcd119643ecdb92d64e    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 17 Feb 2014 09:33:31 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 17 Feb 2014 09:33:31 -0500    

Click here for diff

Back-patch to 8.4 (all supported versions).  

M doc/src/sgml/config.sgml
M doc/src/sgml/plhandler.sgml

Prevent privilege escalation in explicit calls to PL validators.

commit   : c0ac4c75ff048b8ff6d8436946e9c414c2b64f94    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 17 Feb 2014 09:33:31 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 17 Feb 2014 09:33:31 -0500    

Click here for diff

The primary role of PL validators is to be called implicitly during  
CREATE FUNCTION, but they are also normal functions that a user can call  
explicitly.  Add a permissions check to each validator to ensure that a  
user cannot use explicit validator calls to achieve things he could not  
otherwise achieve.  Back-patch to 8.4 (all supported versions).  
Non-core procedural language extensions ought to make the same two-line  
change to their own validators.  
  
Andres Freund, reviewed by Tom Lane and Noah Misch.  
  
Security: CVE-2014-0061  

M doc/src/sgml/plhandler.sgml
M src/backend/catalog/pg_proc.c
M src/backend/commands/functioncmds.c
M src/backend/utils/fmgr/fmgr.c
M src/include/fmgr.h
M src/pl/plperl/plperl.c
M src/pl/plpgsql/src/pl_handler.c

Shore up ADMIN OPTION restrictions.

commit   : 789063697908d7531fc4fe9c72976ea642e68d15    
  
author   : Noah Misch <noah@leadboat.com>    
date     : Mon, 17 Feb 2014 09:33:31 -0500    
  
committer: Noah Misch <noah@leadboat.com>    
date     : Mon, 17 Feb 2014 09:33:31 -0500    

Click here for diff

Granting a role without ADMIN OPTION is supposed to prevent the grantee  
from adding or removing members from the granted role.  Issuing SET ROLE  
before the GRANT bypassed that, because the role itself had an implicit  
right to add or remove members.  Plug that hole by recognizing that  
implicit right only when the session user matches the current role.  
Additionally, do not recognize it during a security-restricted operation  
or during execution of a SECURITY DEFINER function.  The restriction on  
SECURITY DEFINER is not security-critical.  However, it seems best for a  
user testing his own SECURITY DEFINER function to see the same behavior  
others will see.  Back-patch to 8.4 (all supported versions).  
  
The SQL standards do not conflate roles and users as PostgreSQL does;  
only SQL roles have members, and only SQL users initiate sessions.  An  
application using PostgreSQL users and roles as SQL users and roles will  
never attempt to grant membership in the role that is the session user,  
so the implicit right to add or remove members will never arise.  
  
The security impact was mostly that a role member could revoke access  
from others, contrary to the wishes of his own grantor.  Unapproved role  
member additions are less notable, because the member can still largely  
achieve that by creating a view or a SECURITY DEFINER function.  
  
Reviewed by Andres Freund and Tom Lane.  Reported, independently, by  
Jonas Sundman and Noah Misch.  
  
Security: CVE-2014-0060  

M doc/src/sgml/ref/grant.sgml
M src/backend/commands/user.c
M src/backend/utils/adt/acl.c
M src/test/regress/expected/privileges.out
M src/test/regress/sql/privileges.sql

Release notes for 9.3.3, 9.2.7, 9.1.12, 9.0.16, 8.4.20.

commit   : ee58b9451c043081f8b179120c3a3499ec14dfc6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Feb 2014 22:08:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Feb 2014 22:08:40 -0500    

Click here for diff

M doc/src/sgml/release-8.4.sgml
M doc/src/sgml/release-9.0.sgml

Ooops, forgot to remove solar87 and friends from src/timezone/Makefile.

commit   : 0391472baedae2870d67e04b522a1355551e7f47    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Feb 2014 23:20:08 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Feb 2014 23:20:08 -0500    

Click here for diff

Per buildfarm.  

M src/timezone/Makefile

Update time zone data files to tzdata release 2013i.

commit   : cb84fddd908f481b4e80a0af94937aaa9f307ee2    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Feb 2014 21:59:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Feb 2014 21:59:13 -0500    

Click here for diff

DST law changes in Jordan; historical changes in Cuba.  
  
Also, remove the zones Asia/Riyadh87, Asia/Riyadh88, and Asia/Riyadh89.  
Per the upstream announcement:  
    The files solar87, solar88, and solar89 are no longer distributed.  
    They were a negative experiment -- that is, a demonstration that  
    tz data can represent solar time only with some difficulty and error.  
    Their presence in the distribution caused confusion, as Riyadh  
    civil time was generally not solar time in those years.  

M src/timezone/data/asia
M src/timezone/data/northamerica
D src/timezone/data/solar87
D src/timezone/data/solar88
D src/timezone/data/solar89

Suggest shell here-documents instead of psql -c for multiple commands.

commit   : 4588e330442fe130bbdcf4bdd4c35fc19deb329d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Feb 2014 12:54:53 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Feb 2014 12:54:53 -0500    

Click here for diff

The documentation suggested using "echo | psql", but not the often-superior  
alternative of a here-document.  Also, be more direct about suggesting  
that people avoid -c for multiple commands.  Per discussion.  

M doc/src/sgml/ref/psql-ref.sgml

Clean up error cases in psql's COPY TO STDOUT/FROM STDIN code.

commit   : 218dd205b52b16c42562f58456f46b9628c0a0e9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Feb 2014 18:45:27 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Feb 2014 18:45:27 -0500    

Click here for diff

Adjust handleCopyOut() to stop trying to write data once it's failed  
one time.  For typical cases such as out-of-disk-space or broken-pipe,  
additional attempts aren't going to do anything but waste time, and  
in any case clean truncation of the output seems like a better behavior  
than randomly dropping blocks in the middle.  
  
Also remove dubious (and misleadingly documented) attempt to force our way  
out of COPY_OUT state if libpq didn't do that.  If we did have a situation  
like that, it'd be a bug in libpq and would be better fixed there, IMO.  
We can hope that commit fa4440f51628d692f077d54b8313aea31af087ea took care  
of any such problems, anyway.  
  
Also fix longstanding bug in handleCopyIn(): PQputCopyEnd() only supports  
a non-null errormsg parameter in protocol version 3, and will actively  
fail if one is passed in version 2.  This would've made our attempts  
to get out of COPY_IN state after a failure into infinite loops when  
talking to pre-7.4 servers.  
  
Back-patch the COPY_OUT state change business back to 9.2 where it was  
introduced, and the other two fixes into all supported branches.  

M src/bin/psql/copy.c

Fix length checking for Unicode identifiers containing escapes (U&"...").

commit   : 148052d2593becc429425050c8259b05afea0f91    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Feb 2014 14:24:55 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Feb 2014 14:24:55 -0500    

Click here for diff

We used the length of the input string, not the de-escaped string, as  
the trigger for NAMEDATALEN truncation.  AFAICS this would only result  
in sometimes printing a phony truncation warning; but it's just luck  
that there was no worse problem, since we were violating the API spec  
for truncate_identifier().  Per bug #9204 from Joshua Yanovski.  
  
This has been wrong since the Unicode-identifier support was added,  
so back-patch to all supported branches.  

M src/backend/parser/scan.l

Improve cross-references between minor version release notes.

commit   : 16b06c994f5d7d471f7284afdcd02c0a9ac93be1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Feb 2014 19:09:30 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Feb 2014 19:09:30 -0500    

Click here for diff

We have a practice of providing a "bread crumb" trail between the minor  
versions where the migration section actually tells you to do something.  
Historically that was just plain text, eg, "see the release notes for  
9.2.4"; but if you're using a browser or PDF reader, it's a lot nicer  
if it's a live hyperlink.  So use "<xref>" instead.  Any argument against  
doing this vanished with the recent decommissioning of plain-text release  
notes.  
  
Vik Fearing  

M doc/src/sgml/release-7.4.sgml
M doc/src/sgml/release-8.0.sgml
M doc/src/sgml/release-8.1.sgml
M doc/src/sgml/release-8.2.sgml
M doc/src/sgml/release-8.3.sgml
M doc/src/sgml/release-8.4.sgml
M doc/src/sgml/release-9.0.sgml
M doc/src/sgml/release-old.sgml

Improve text of stub HISTORY file.

commit   : c90859fd761a24abc5fe4109514827bdf559099b    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Feb 2014 18:16:17 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Feb 2014 18:16:17 -0500    

Click here for diff

Per Peter Eisentraut.  

M HISTORY

Improve libpq's error recovery for connection loss during COPY.

commit   : a88a371399807219f7e3e59c90fb4058da79bab4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Feb 2014 17:50:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Feb 2014 17:50:20 -0500    

Click here for diff

In pqSendSome, if the connection is already closed at entry, discard any  
queued output data before returning.  There is no possibility of ever  
sending the data, and anyway this corresponds to what we'd do if we'd  
detected a hard error while trying to send().  This avoids possible  
indefinite bloat of the output buffer if the application keeps trying  
to send data (or even just keeps trying to do PQputCopyEnd, as psql  
indeed will).  
  
Because PQputCopyEnd won't transition out of PGASYNC_COPY_IN state  
until it's successfully queued the COPY END message, and pqPutMsgEnd  
doesn't distinguish a queuing failure from a pqSendSome failure,  
this omission allowed an infinite loop in psql if the connection closure  
occurred when we had at least 8K queued to send.  It might be worth  
refactoring so that we can make that distinction, but for the moment  
the other changes made here seem to offer adequate defenses.  
  
To guard against other variants of this scenario, do not allow  
PQgetResult to return a PGRES_COPY_XXX result if the connection is  
already known dead.  Make sure it returns PGRES_FATAL_ERROR instead.  
  
Per report from Stephen Frost.  Back-patch to all active branches.  

M src/interfaces/libpq/fe-exec.c
M src/interfaces/libpq/fe-misc.c

In XLogReadBufferExtended, don't assume P_NEW yields consecutive pages.

commit   : 7fedd79b71c212d6e83dbe9af75c4ae3c7b89753    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Feb 2014 14:52:29 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Feb 2014 14:52:29 -0500    

Click here for diff

In a database that's not yet reached consistency, it's possible that some  
segments of a relation are not full-size but are not the last ones either.  
Because of the way smgrnblocks() works, asking for a new page with P_NEW  
will fill in the last not-full-size segment --- and if that makes it full  
size, the apparent EOF of the relation will increase by more than one page,  
so that the next P_NEW request will yield a page past the next consecutive  
one.  This breaks the relation-extension logic in XLogReadBufferExtended,  
possibly allowing a page update to be applied to some page far past where  
it was intended to go.  This appears to be the explanation for reports of  
table bloat on replication slaves compared to their masters, and probably  
explains some corrupted-slave reports as well.  
  
Fix the loop to check the page number it actually got, rather than merely  
Assert()'ing that dead reckoning got it to the desired place.  AFAICT,  
there are no other places that make assumptions about exactly which page  
they'll get from P_NEW.  
  
Problem identified by Greg Stark, though this is not the same as his  
proposed patch.  
  
It's been like this for a long time, so back-patch to all supported  
branches.  

M src/backend/access/transam/xlogutils.c

Don't generate plain-text HISTORY and src/test/regress/README anymore.

commit   : e1e7642bd3bdde980c481c5feb7739c4f841f757    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Feb 2014 20:48:27 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Feb 2014 20:48:27 -0500    

Click here for diff

Providing this information as plain text was doubtless worth the trouble  
ten years ago, but it seems likely that hardly anyone reads it in this  
format anymore.  And the effort required to maintain these files (in the  
form of extra-complex markup rules in the relevant parts of the SGML  
documentation) is significant.  So, let's stop doing that and rely solely  
on the other documentation formats.  
  
Per discussion, the plain-text INSTALL instructions might still be worth  
their keep, so we continue to generate that file.  
  
Rather than remove HISTORY and src/test/regress/README from distribution  
tarballs entirely, replace them with simple stub files that tell the reader  
where to find the relevant documentation.  This is mainly to avoid possibly  
breaking packaging recipes that expect these files to exist.  
  
Back-patch to all supported branches, because simplifying the markup  
requirements for release notes won't help much unless we do it in all  
branches.  

M GNUmakefile.in
A HISTORY
M README
M README.git
M doc/src/sgml/.gitignore
M doc/src/sgml/Makefile
M doc/src/sgml/docguide.sgml
D doc/src/sgml/generate_history.pl
M doc/src/sgml/release.sgml
M doc/src/sgml/standalone-install.sgml
A src/test/regress/README
M src/tools/RELEASE_CHANGES

Use memmove() instead of memcpy() for copying overlapping regions.

commit   : fe8a6f53e07d2686e3238a237ec64e0fc2d4b123    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 10 Feb 2014 09:55:14 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 10 Feb 2014 09:55:14 +0200    

Click here for diff

In commit d2495f272cd164ff075bee5c4ce95aed11338a36, I fixed this bug in  
to_tsquery(), but missed the fact that plainto_tsquery() has the same bug.  

M src/backend/tsearch/to_tsany.c

Fix makefile syntax.

commit   : c73423d9772ef322fd84f76af5340f2b19337c21    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 1 Feb 2014 19:51:48 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 1 Feb 2014 19:51:48 -0500    

Click here for diff

M src/interfaces/libpq/Makefile

Fix some wide-character bugs in the text-search parser.

commit   : 3c7b4ef70fb443aeab7fd711ee94453a41d69d77    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Feb 2014 18:27:07 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Feb 2014 18:27:07 -0500    

Click here for diff

In p_isdigit and other character class test functions generated by the  
p_iswhat macro, the code path for non-C locales with multibyte encodings  
contained a bogus pointer cast that would accidentally fail to malfunction  
if types wchar_t and wint_t have the same width.  Apparently that is true  
on most platforms, but not on recent Cygwin releases.  Remove the cast,  
as it seems completely unnecessary (I think it arose from a false analogy  
to the need to cast to unsigned char when dealing with the <ctype.h>  
functions).  Per bug #8970 from Marco Atzeri.  
  
In the same functions, the code path for C locale with a multibyte encoding  
simply ANDed each wide character with 0xFF before passing it to the  
corresponding <ctype.h> function.  This could result in false positive  
answers for some non-ASCII characters, so use a range test instead.  
Noted by me while investigating Marco's complaint.  
  
Also, remove some useless though not actually buggy maskings and casts  
in the hand-coded p_isalnum and p_isalpha functions, which evidently  
got tested a bit more carefully than the macro-generated functions.  

M src/backend/tsearch/wparser_def.c

fix whitespace

commit   : cfebd60d826a4c34f240913ee9c76d4e9ac0afa9    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 1 Feb 2014 16:26:31 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 1 Feb 2014 16:26:31 -0500    

Click here for diff

M src/Makefile.shlib

Don't use deprecated dllwrap on Cygwin.

commit   : 1c0bf372fa185278856970c4e80d7714570392d1    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 1 Feb 2014 16:14:15 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 1 Feb 2014 16:14:15 -0500    

Click here for diff

The preferred method is to use "cc -shared", and this allows binaries  
to be rebased if required, unlike dllwrap.  
  
Backpatch to 9.0 where we have buildfarm coverage.  
  
There are still some issues with Cygwin, especially modern Cygwin, but  
this helps us get closer to good support.  
  
Marco Atzeri.  

M src/Makefile.shlib
M src/makefiles/Makefile.cygwin

Copy the libpq DLL to the bin directory on Mingw and Cygwin.

commit   : 59d64e7f30106e467ac1efa29f15d805da630ac9    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 1 Feb 2014 15:16:40 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 1 Feb 2014 15:16:40 -0500    

Click here for diff

This has long been done by the MSVC build system, and has caused  
confusion in the past when programs like psql have failed to start  
because they can't find the DLL. If it's in the same directory as it now  
will be they will find it.  
  
Backpatch to all live branches.  

M src/interfaces/libpq/Makefile

Clear MyProc and MyProcSignalState before they become invalid.

commit   : 798243a8126b137791ee87cfc78839cf1732c50d    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Fri, 31 Jan 2014 21:31:08 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Fri, 31 Jan 2014 21:31:08 -0500    

Click here for diff

Evidence from buildfarm member crake suggests that the new test_shm_mq  
module is routinely crashing the server due to the arrival of a SIGUSR1  
after the shared memory segment has been unmapped.  Although processes  
using the new dynamic background worker facilities are more likely to  
receive a SIGUSR1 around this time, the problem is also possible on older  
branches, so I'm back-patching the parts of this change that apply to  
older branches as far as they apply.  
  
It's already generally the case that code checks whether these pointers  
are NULL before deferencing them, so the important thing is mostly to  
make sure that they do get set to NULL before they become invalid.  But  
in master, there's one case in procsignal_sigusr1_handler that lacks a  
NULL guard, so add that.  
  
Patch by me; review by Tom Lane.  

M src/backend/storage/ipc/procsignal.c
M src/backend/storage/lmgr/proc.c

Fix unsafe references to errno within error messaging logic.

commit   : d17a667e8038c021eb38c203cc7aac2ea9dac0df    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jan 2014 20:04:11 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jan 2014 20:04:11 -0500    

Click here for diff

Various places were supposing that errno could be expected to hold still  
within an ereport() nest or similar contexts.  This isn't true necessarily,  
though in some cases it accidentally failed to fail depending on how the  
compiler chanced to order the subexpressions.  This class of thinko  
explains recent reports of odd failures on clang-built versions, typically  
missing or inappropriate HINT fields in messages.  
  
Problem identified by Christian Kruse, who also submitted the patch this  
commit is based on.  (I fixed a few issues in his patch and found a couple  
of additional places with the same disease.)  
  
Back-patch as appropriate to all supported branches.  

M src/backend/commands/tablespace.c
M src/backend/port/sysv_sema.c
M src/backend/port/sysv_shmem.c

Fix bugs in PQhost().

commit   : 996b21cbf24d0ff2ee16c1043fe443ae623474ea    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 23 Jan 2014 23:02:03 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 23 Jan 2014 23:02:03 +0900    

Click here for diff

In the platform that doesn't support Unix-domain socket, when  
neither host nor hostaddr are specified, the default host  
'localhost' is used to connect to the server and PQhost() must  
return that, but it didn't. This patch fixes PQhost() so that  
it returns the default host in that case.  
  
Also this patch fixes PQhost() so that it doesn't return  
Unix-domain socket directory path in the platform that doesn't  
support Unix-domain socket.  
  
Back-patch to all supported versions.  

M src/interfaces/libpq/fe-connect.c

Allow type_func_name_keywords in even more places

commit   : f2eede9b584305472dd3fd58e1690766c378ab34    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Tue, 21 Jan 2014 22:49:22 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Tue, 21 Jan 2014 22:49:22 -0500    

Click here for diff

A while back, 2c92edad48796119c83d7dbe6c33425d1924626d allowed  
type_func_name_keywords to be used in more places, including role  
identifiers.  Unfortunately, that commit missed out on cases where  
name_list was used for lists-of-roles, eg: for DROP ROLE.  This  
resulted in the unfortunate situation that you could CREATE a role  
with a type_func_name_keywords-allowed identifier, but not DROP it  
(directly- ALTER could be used to rename it to something which  
could be DROP'd).  
  
This extends allowing type_func_name_keywords to places where role  
lists can be used.  
  
Back-patch to 9.0, as 2c92edad48796119c83d7dbe6c33425d1924626d was.  

M src/backend/parser/gram.y

Allow SET TABLESPACE to database default

commit   : e70c4282136e07ab3a0e57f3c811de80e4318d9f    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Sat, 18 Jan 2014 18:41:52 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Sat, 18 Jan 2014 18:41:52 -0500    

Click here for diff

We've always allowed CREATE TABLE to create tables in the database's default  
tablespace without checking for CREATE permissions on that tablespace.  
Unfortunately, the original implementation of ALTER TABLE ... SET TABLESPACE  
didn't pick up on that exception.  
  
This changes ALTER TABLE ... SET TABLESPACE to allow the database's default  
tablespace without checking for CREATE rights on that tablespace, just as  
CREATE TABLE works today.  Users could always do this through a series of  
commands (CREATE TABLE ... AS SELECT * FROM ...; DROP TABLE ...; etc), so  
let's fix the oversight in SET TABLESPACE's original implementation.  

M src/backend/commands/tablecmds.c

Fix client-only installation

commit   : 2346c383af7d9dbb2b8609cc407658ff30f86155    
  
author   : Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 17 Jan 2014 23:08:22 -0500    
  
committer: Peter Eisentraut <peter_e@gmx.net>    
date     : Fri, 17 Jan 2014 23:08:22 -0500    

Click here for diff

The psql Makefile was not creating $(datadir) before installing  
psqlrc.sample there.  
  
In most cases, the directory would be created in some other way, but for  
the documented from-source client-only installation procedure, it could  
fail.  
  
Reported-by: Mike Blackwell <mike.blackwell@rrd.com>  

M src/bin/psql/Makefile

Fix multiple bugs in index page locking during hot-standby WAL replay.

commit   : 5d742b9ce119739c32a08f0e20a2d89102e489dd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Jan 2014 17:35:00 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Jan 2014 17:35:00 -0500    

Click here for diff

In ordinary operation, VACUUM must be careful to take a cleanup lock on  
each leaf page of a btree index; this ensures that no indexscans could  
still be "in flight" to heap tuples due to be deleted.  (Because of  
possible index-tuple motion due to concurrent page splits, it's not enough  
to lock only the pages we're deleting index tuples from.)  In Hot Standby,  
the WAL replay process must likewise lock every leaf page.  There were  
several bugs in the code for that:  
  
* The replay scan might come across unused, all-zero pages in the index.  
While btree_xlog_vacuum itself did the right thing (ie, nothing) with  
such pages, xlogutils.c supposed that such pages must be corrupt and  
would throw an error.  This accounts for various reports of replication  
failures with "PANIC: WAL contains references to invalid pages".  To  
fix, add a ReadBufferMode value that instructs XLogReadBufferExtended  
not to complain when we're doing this.  
  
* btree_xlog_vacuum performed the extra locking if standbyState ==  
STANDBY_SNAPSHOT_READY, but that's not the correct test: we won't open up  
for hot standby queries until the database has reached consistency, and  
we don't want to do the extra locking till then either, for fear of reading  
corrupted pages (which bufmgr.c would complain about).  Fix by exporting a  
new function from xlog.c that will report whether we're actually in hot  
standby replay mode.  
  
* To ensure full coverage of the index in the replay scan, btvacuumscan  
would emit a dummy WAL record for the last page of the index, if no  
vacuuming work had been done on that page.  However, if the last page  
of the index is all-zero, that would result in corruption of said page,  
since the functions called on it weren't prepared to handle that case.  
There's no need to lock any such pages, so change the logic to target  
the last normal leaf page instead.  
  
The first two of these bugs were diagnosed by Andres Freund, the other one  
by me.  Fixes based on ideas from Heikki Linnakangas and myself.  
  
This has been wrong since Hot Standby was introduced, so back-patch to 9.0.  

M src/backend/access/nbtree/nbtree.c
M src/backend/access/nbtree/nbtxlog.c
M src/backend/access/transam/xlog.c
M src/backend/access/transam/xlogutils.c
M src/backend/storage/buffer/bufmgr.c
M src/include/access/xlog.h
M src/include/storage/bufmgr.h

Fix possible buffer overrun in contrib/pg_trgm.

commit   : f261ad241daa37e3e040e2a43727a3b5703eff87    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Jan 2014 13:07:23 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Jan 2014 13:07:23 -0500    

Click here for diff

Allow for the possibility that folding a string to lower case makes it  
longer (due to replacing a character with a longer multibyte character).  
This doesn't change the number of trigrams that will be extracted, but  
it does affect the required size of an intermediate buffer in  
generate_trgm().  Per bug #8821 from Ufuk Kayserilioglu.  
  
Also install some checks that the input string length is not so large  
as to cause overflow in the calculations of palloc request sizes.  
  
Back-patch to all supported versions.  

M contrib/pg_trgm/trgm_op.c

Fix calculation of ISMN check digit.

commit   : 6c3f040be864c39e2b12581ab69c5f2a21d11968    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 13 Jan 2014 15:42:35 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 13 Jan 2014 15:42:35 +0200    

Click here for diff

This has always been broken, so back-patch to all supported versions.  
  
Fabien COELHO  

M contrib/isn/isn.c

Fix possible crashes due to using elog/ereport too early in startup.

commit   : d9c4442b88450cb0cae007ca8ed6207d0d9e6d34    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Jan 2014 16:35:41 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Jan 2014 16:35:41 -0500    

Click here for diff

Per reports from Andres Freund and Luke Campbell, a server failure during  
set_pglocale_pgservice results in a segfault rather than a useful error  
message, because the infrastructure needed to use ereport hasn't been  
initialized; specifically, MemoryContextInit hasn't been called.  
One known cause of this is starting the server in a directory it  
doesn't have permission to read.  
  
We could try to prevent set_pglocale_pgservice from using anything that  
depends on palloc or elog, but that would be messy, and the odds of future  
breakage seem high.  Moreover there are other things being called in main.c  
that look likely to use palloc or elog too --- perhaps those things  
shouldn't be there, but they are there today.  The best solution seems to  
be to move the call of MemoryContextInit to very early in the backend's  
real main() function.  I've verified that an elog or ereport occurring  
immediately after that is now capable of sending something useful to  
stderr.  
  
I also added code to elog.c to print something intelligible rather than  
just crashing if MemoryContextInit hasn't created the ErrorContext.  
This could happen if MemoryContextInit itself fails (due to malloc  
failure), and provides some future-proofing against someone trying to  
sneak in new code even earlier in server startup.  
  
Back-patch to all supported branches.  Since we've only heard reports of  
this type of failure recently, it may be that some recent change has made  
it more likely to see a crash of this kind; but it sure looks like it's  
broken all the way back.  

M src/backend/bootstrap/bootstrap.c
M src/backend/main/main.c
M src/backend/postmaster/postmaster.c
M src/backend/tcop/postgres.c
M src/backend/utils/error/elog.c
M src/backend/utils/mmgr/mcxt.c

Fix compute_scalar_stats() for case that all values exceed WIDTH_THRESHOLD.

commit   : 2d76d75d940759d6b734533ca61b8b59dc2acce1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Jan 2014 13:41:41 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Jan 2014 13:41:41 -0500    

Click here for diff

The standard typanalyze functions skip over values whose detoasted size  
exceeds WIDTH_THRESHOLD (1024 bytes), so as to limit memory bloat during  
ANALYZE.  However, we (I think I, actually :-() failed to consider the  
possibility that *every* non-null value in a column is too wide.  While  
compute_minimal_stats() seems to behave reasonably anyway in such a case,  
compute_scalar_stats() just fell through and generated no pg_statistic  
entry at all.  That's unnecessarily pessimistic: we can still produce  
valid stanullfrac and stawidth values in such cases, since we do include  
too-wide values in the average-width calculation.  Furthermore, since the  
general assumption in this code is that too-wide values are probably all  
distinct from each other, it seems reasonable to set stadistinct to -1  
("all distinct").  
  
Per complaint from Kadri Raudsepp.  This has been like this since roughly  
neolithic times, so back-patch to all supported branches.  

M src/backend/commands/analyze.c

Fix descriptor output in ECPG.

commit   : a29b6c34209a54e570338fcec343b11286005685    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Thu, 9 Jan 2014 15:41:51 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Thu, 9 Jan 2014 15:41:51 +0100    

Click here for diff

While working on most platforms the old way sometimes created alignment  
problems. This should fix it. Also the regresion tests were updated to test for  
the reported case.  
  
Report and fix by MauMau <maumau307@gmail.com>  

M src/interfaces/ecpg/preproc/type.c
M src/interfaces/ecpg/test/expected/compat_informix-describe.c
M src/interfaces/ecpg/test/expected/sql-desc.c
M src/interfaces/ecpg/test/expected/sql-describe.c
M src/interfaces/ecpg/test/expected/sql-dynalloc.c
M src/interfaces/ecpg/test/expected/sql-dynalloc2.c
M src/interfaces/ecpg/test/expected/sql-dyntest.c

Fix "cannot accept a set" error when only some arms of a CASE return a set.

commit   : 6ca712fb906776818ba46e2dfc26ffc4592a64fa    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Jan 2014 20:18:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Jan 2014 20:18:20 -0500    

Click here for diff

In commit c1352052ef1d4eeb2eb1d822a207ddc2d106cb13, I implemented an  
optimization that assumed that a function's argument expressions would  
either always return a set (ie multiple rows), or always not.  This is  
wrong however: we allow CASE expressions in which some arms return a set  
of some type and others just return a scalar of that type.  There may be  
other examples as well.  To fix, replace the run-time test of whether an  
argument returned a set with a static precheck (expression_returns_set).  
This adds a little bit of query startup overhead, but it seems barely  
measurable.  
  
Per bug #8228 from David Johnston.  This has been broken since 8.0,  
so patch all supported branches.  

M src/backend/executor/execQual.c
M src/test/regress/expected/rangefuncs.out
M src/test/regress/sql/rangefuncs.sql

Fix bug in determining when recovery has reached consistency.

commit   : 5301c839533203ec7020497bf7c06432f6adfb5b    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 8 Jan 2014 11:39:55 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 8 Jan 2014 11:39:55 +0200    

Click here for diff

When starting WAL replay from an online checkpoint, the last replayed WAL  
record variable was initialized using the checkpoint record's location, even  
though the records between the REDO location and the checkpoint record had  
not been replayed yet. That was noted as "slightly confusing" but harmless  
in the comment, but in some cases, it fooled CheckRecoveryConsistency to  
incorrectly conclude that we had already reached a consistent state  
immediately at the beginning of WAL replay. That caused the system to accept  
read-only connections in hot standby mode too early, and also PANICs with  
message "WAL contains references to invalid pages".  
  
Fix by initializing the variables to the REDO location instead.  
  
In 9.2 and above, change CheckRecoveryConsistency() to use  
lastReplayedEndRecPtr variable when checking if backup end location has  
been reached. It was inconsistently using EndRecPtr for that check, but  
lastReplayedEndRecPtr when checking min recovery point. It made no  
difference before this patch, because in all the places where  
CheckRecoveryConsistency was called the two variables were the same, but  
it was always an accident waiting to happen, and would have been wrong  
after this patch anyway.  
  
Report and analysis by Tomonari Katsumata, bug #8686. Backpatch to 9.0,  
where hot standby was introduced.  

M src/backend/access/transam/xlog.c

commit   : a44a0b9cb52629b3ce2756462deaa4d407ac6dd5    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Tue, 7 Jan 2014 16:05:29 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Tue, 7 Jan 2014 16:05:29 -0500    

Click here for diff

Update all files in head, and files COPYRIGHT and legal.sgml in all back  
branches.  

M COPYRIGHT
M doc/src/sgml/legal.sgml

Do not use an empty hostname.

commit   : 17bcdd01f3615d719ef53680b0bd316424d6b706    
  
author   : Michael Meskes <meskes@postgresql.org>    
date     : Wed, 1 Jan 2014 12:24:19 +0100    
  
committer: Michael Meskes <meskes@postgresql.org>    
date     : Wed, 1 Jan 2014 12:24:19 +0100    

Click here for diff

When trying to connect to a given database libecpg should not try using an  
empty hostname if no hostname was given.  

M src/interfaces/ecpg/ecpglib/connect.c

Don't attempt to limit target database for pg_restore.

commit   : 8d65ea20f6ed31159768c643035093cd719393c7    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Sun, 29 Dec 2013 15:19:19 -0600    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Sun, 29 Dec 2013 15:19:19 -0600    

Click here for diff

There was an apparent attempt to limit the target database for  
pg_restore to version 7.1.0 or later.  Due to a leading zero this  
was interpreted as an octal number, which allowed targets with  
version numbers down to 2.87.36.  The lowest actual release above  
that was 6.0.0, so that was effectively the limit.  
  
Since the success of the restore attempt will depend primarily on  
on what statements were generated by the dump run, we don't want  
pg_restore trying to guess whether a given target should be allowed  
based on version number.  Allow a connection to any version.  Since  
it is very unlikely that anyone would be using a recent version of  
pg_restore to restore to a pre-6.0 database, this has little to no  
practical impact, but it makes the code less confusing to read.  
  
Issue reported and initial patch suggestion from Joel Jacobson  
based on an article by Andrey Karpov reporting on issues found by  
PVS-Studio static code analyzer.  Final patch based on analysis by  
Tom Lane.  Back-patch to all supported branches.  

M src/bin/pg_dump/pg_backup_archiver.c

Fix misplaced right paren bugs in pgstatfuncs.c.

commit   : 918d74a07e5fbaa1858e89b345b4daa10c667292    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 27 Dec 2013 15:41:32 -0600    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 27 Dec 2013 15:41:32 -0600    

Click here for diff

The bug would only show up if the C sockaddr structure contained  
zero in the first byte for a valid address; otherwise it would  
fail to fail, which is probably why it went unnoticed for so long.  
  
Patch submitted by Joel Jacobson after seeing an article by Andrey  
Karpov in which he reports finding this through static code  
analysis using PVS-Studio.  While I was at it I moved a definition  
of a local variable referenced in the buggy code to a more local  
context.  
  
Backpatch to all supported branches.  

M src/backend/utils/adt/pgstatfuncs.c

Add "SHIFT_JIS" as an accepted encoding name for locale checking.

commit   : 7016d970d0f1f3a59249a28c6148158bc47c6bd8    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 15 Dec 2013 10:33:06 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Sun, 15 Dec 2013 10:33:06 +0900    

Click here for diff

When locale is "ja_JP.SJIS", nl_langinfo(CODESET) returns "SHIFT_JIS"  
on some platforms, at least on RedHat Linux. So the encoding/locale  
match table (encoding_match_list) needs the entry. Otherwise client  
encoding is set to SQL_ASCII.  
  
Back patch to all supported branches.  

M src/port/chklocale.c

Add HOLD/RESUME_INTERRUPTS in HandleCatchupInterrupt/HandleNotifyInterrupt.

commit   : 0a63f7d977777fc934589bdd7229929ab0325d55    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Dec 2013 14:05:27 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Dec 2013 14:05:27 -0500    

Click here for diff

This prevents a possible longjmp out of the signal handler if a timeout  
or SIGINT occurs while something within the handler has transiently set  
ImmediateInterruptOK.  For safety we must hold off the timeout or cancel  
error until we're back in mainline, or at least till we reach the end of  
the signal handler when ImmediateInterruptOK was true at entry.  This  
syncs these functions with the logic now present in handle_sig_alarm.  
  
AFAICT there is no live bug here in 9.0 and up, because I don't think we  
currently can wait for any heavyweight lock inside these functions, and  
there is no other code (except read-from-client) that will turn on  
ImmediateInterruptOK.  However, that was not true pre-9.0: in older  
branches ProcessIncomingNotify might block trying to lock pg_listener, and  
then a SIGINT could lead to undesirable control flow.  It might be all  
right anyway given the relatively narrow code ranges in which NOTIFY  
interrupts are enabled, but for safety's sake I'm back-patching this.  

M src/backend/commands/async.c
M src/backend/storage/ipc/sinval.c

Fix ancient docs/comments thinko: XID comparison is mod 2^32, not 2^31.

commit   : 607f889c71dd202008173a23115cc51dcad1c73d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Dec 2013 12:40:03 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Dec 2013 12:40:03 -0500    

Click here for diff

Pointed out by Gianni Ciolli.  

M doc/src/sgml/maintenance.sgml
M src/backend/access/transam/transam.c

Tweak placement of explicit ANALYZE commands in the regression tests.

commit   : 7d6f5dda55f6dc49fc18ce1409e2add34a2cef13    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Dec 2013 15:08:45 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Dec 2013 15:08:45 -0500    

Click here for diff

Make the COPY test, which loads most of the large static tables used in  
the tests, also explicitly ANALYZE those tables.  This allows us to get  
rid of various ad-hoc, and rather redundant, ANALYZE commands that had  
gotten stuck into various test scripts over time to ensure we got  
consistent plan choices.  (We could have done a database-wide ANALYZE,  
but that would cause stats to get attached to the small static tables  
too, which results in plan changes compared to the historical behavior.  
I'm not sure that's a good idea, so not going that far for now.)  
  
Back-patch to 9.0, since 9.0 and 9.1 are currently sometimes failing  
regression tests for lack of an "ANALYZE tenk1" in the subselect test.  
There's no need for this in 8.4 since we didn't print any plans back  
then.  

M src/test/regress/expected/alter_table.out
M src/test/regress/expected/join.out
M src/test/regress/input/copy.source
M src/test/regress/output/copy.source
M src/test/regress/sql/alter_table.sql
M src/test/regress/sql/join.sql

commit   : 41e9990cdcb37ec0b1fecee4a1a5a70cc6578d60    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Dec 2013 16:10:31 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Dec 2013 16:10:31 -0500    

Click here for diff

An expression such as WHERE (... x IN (SELECT ...) ...) IN (SELECT ...)  
could produce an invalid plan that results in a crash at execution time,  
if the planner attempts to flatten the outer IN into a semi-join.  
This happens because convert_testexpr() was not expecting any nested  
SubLinks and would wrongly replace any PARAM_SUBLINK Params belonging  
to the inner SubLink.  (I think the comment denying that this case could  
happen was wrong when written; it's certainly been wrong for quite a long  
time, since very early versions of the semijoin flattening logic.)  
  
Per report from Teodor Sigaev.  Back-patch to all supported branches.  

M src/backend/optimizer/plan/subselect.c
M src/test/regress/expected/subselect.out
M src/test/regress/sql/subselect.sql

commit   : 9057adc23252be03056088e606fa13d174493578    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sat, 7 Dec 2013 16:58:41 -0800    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sat, 7 Dec 2013 16:58:41 -0800    

Click here for diff

Previous commit e5de601267d98c5d60df6de8d436685c7105d149 modified dblink  
to ensure client encoding matched the server. However the added  
PQsetClientEncoding() call added significant overhead. Restore original  
performance in the common case where client encoding already matches  
server encoding by doing nothing in that case. Applies to all active  
branches.  
  
Issue reported and work sponsored by Zonar Systems.  

M contrib/dblink/dblink.c

Clear retry flags properly in replacement OpenSSL sock_write function.

commit   : 36352ceb40bd6b19b0595f7d8bb93cc64897abbb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Dec 2013 12:48:41 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Dec 2013 12:48:41 -0500    

Click here for diff

Current OpenSSL code includes a BIO_clear_retry_flags() step in the  
sock_write() function.  Either we failed to copy the code correctly, or  
they added this since we copied it.  In any case, lack of the clear step  
appears to be the cause of the server lockup after connection loss reported  
in bug #8647 from Valentine Gogichashvili.  Assume that this is correct  
coding for all OpenSSL versions, and hence back-patch to all supported  
branches.  
  
Diagnosis and patch by Alexander Kukushkin.  

M src/backend/libpq/be-secure.c

Fix full-page writes of internal GIN pages.

commit   : 760606dc5820fa9a849929e4ef35b98b2cdc9994    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 3 Dec 2013 22:13:16 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Tue, 3 Dec 2013 22:13:16 +0200    

Click here for diff

Insertion to a non-leaf GIN page didn't make a full-page image of the page,  
which is wrong. The code used to do it correctly, but was changed (commit  
853d1c3103fa961ae6219f0281885b345593d101) because the redo-routine didn't  
track incomplete splits correctly when the page was restored from a full  
page image. Of course, that was not right way to fix it, the redo routine  
should've been fixed instead. The redo-routine was surreptitiously fixed  
in 2010 (commit 4016bdef8aded77b4903c457050622a5a1815c16), so all we need  
to do now is revert the code that creates the record to its original form.  
  
This doesn't change the format of the WAL record.  
  
Backpatch to all supported versions.  

M src/backend/access/gin/gindatapage.c
M src/backend/access/gin/ginentrypage.c