PostgreSQL 9.3.3 commit log

Stamp 9.3.3.

commit   : 0691fe504723c06ce6ccd1de257fe212609beb13    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2014 14:29:55 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2014 14:29:55 -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   : 4239753338c8ef36d26615beb9b567bdd1814f73    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2014 14:25:40 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2014 14:25:40 -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
M doc/src/sgml/release-9.1.sgml
M doc/src/sgml/release-9.2.sgml
M doc/src/sgml/release-9.3.sgml

Improve documentation about multixact IDs.

commit   : 81f4c2867f37f1a2a1c5a4ce337d4f5cd3013bc1    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2014 12:21:01 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2014 12:21:01 -0500    

Click here for diff

Per gripe from Josh Berkus.  

M doc/src/sgml/maintenance.sgml
M doc/src/sgml/release-9.3.sgml

PGDLLIMPORT-ify MyBgworkerEntry.

commit   : 6fc2868e4f97c2918138f0cc43a54d64e6a810fd    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2014 11:29:34 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2014 11:29:34 -0500    

Click here for diff

This was done in HEAD in commit 7d7eee8bb702d7796a0d7c5886c1f4685f2e2806,  
but 9.3 needs it too for contrib/worker_spi.  Per buildfarm member narwhal.  

M src/include/postmaster/bgworker.h

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

commit   : 1ec5988f316be935ae51754f9ff4477968e61354    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2014 11:24:38 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2014 11:24:38 -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   : e3208fec32586076cd1a24cae19ded158a60e15a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2014 11:20:24 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 17 Feb 2014 11:20:24 -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/findtimezone.c
M src/bin/pg_basebackup/pg_basebackup.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   : 7a362a176a5c6621b58fb3897b2a4cb15b975810    
  
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   : e4a4fa22352b062bc3548c91fa9bfc6caed7b073    
  
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   : e1e0a4d791292ebe9572451a6cf49fb0ccb320c7    
  
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/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/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   : 30b1c40f98e5e4d0f3d8ec7673f3fbb8ae8ee43f    
  
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   : fc4a04a3c4f49ac8a74241401ffd5118c4d00842    
  
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
M src/pl/plpython/plpy_main.c

Shore up ADMIN OPTION restrictions.

commit   : 475a1fbc41a120ea3bd5f903e37c48d7a1769ff8    
  
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   : 0a8793333b9b8d21fc62ba0779234d6dc499d610    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Feb 2014 22:08:30 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Feb 2014 22:08:30 -0500    

Click here for diff

M doc/src/sgml/release-8.4.sgml
M doc/src/sgml/release-9.0.sgml
M doc/src/sgml/release-9.1.sgml
M doc/src/sgml/release-9.2.sgml
M doc/src/sgml/release-9.3.sgml

Fix unportable coding in tarCreateHeader().

commit   : 6be49f22f476e5fadf1934cf67f08b12239febdf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Feb 2014 20:01:21 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Feb 2014 20:01:21 -0500    

Click here for diff

uid_t and gid_t might be wider than int on some platforms.  
Per buildfarm member brolga.  

M src/port/tar.c

PGDLLIMPORT'ify DateStyle and IntervalStyle.

commit   : d5a43a238e8179ef4d808acb920bdb7e8c1e3596    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Feb 2014 12:37:10 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 16 Feb 2014 12:37:10 -0500    

Click here for diff

This is needed on Windows to support contrib/postgres_fdw.  Although it's  
been broken since last March, we didn't notice until recently because there  
were no active buildfarm members that complained about missing PGDLLIMPORT  
marking.  Efforts are underway to improve that situation, in support of  
which we're delaying fixing some other cases of global variables that  
should be marked PGDLLIMPORT.  However, this case affects 9.3, so we  
can't wait any longer to fix it.  
  
I chose to mark DateOrder as well, though it's not strictly necessary  
for postgres_fdw.  

M src/include/miscadmin.h

Fix unportable coding in DetermineSleepTime().

commit   : dada4747a0eefc57cf82a27d856562b029813464    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Feb 2014 17:09:54 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 15 Feb 2014 17:09:54 -0500    

Click here for diff

We should not assume that struct timeval.tv_sec is a long, because  
it ain't necessarily.  (POSIX says that it's a time_t, which might  
well be 64 bits now or in the future; or for that matter might be  
32 bits on machines with 64-bit longs.)  Per buildfarm member panther.  
  
Back-patch to 9.3 where the dubious coding was introduced.  

M src/backend/postmaster/postmaster.c

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

commit   : 38855bed5a09a2f005b88b73cf319b32332c4ad3    
  
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   : 46cbcd50e87be0f4734effc7182cb693da83f9f0    
  
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

Update regression testing instructions.

commit   : bfd59426db52b934a3883c7d3a27b2ce8798afe5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Feb 2014 16:50:25 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Feb 2014 16:50:25 -0500    

Click here for diff

This documentation never got the word about the existence of check-world or  
installcheck-world.  Revise to recommend use of those, and document all the  
subsidiary test suites.  Do some minor wordsmithing elsewhere, too.  
  
In passing, remove markup related to generation of plain-text regression  
test instructions, since we don't do that anymore.  
  
Back-patch to 9.1 where check-world was added.  (installcheck-world exists  
in 9.0; but since check-world doesn't, this patch would need additional  
work to cover that branch, and it doesn't seem worth the effort.)  

M doc/src/sgml/regress.sgml

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

commit   : 6cafc4fb09bc3bc56365c5f76f1ceba11ec86088    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Feb 2014 12:54:43 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 14 Feb 2014 12:54:43 -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

Change the order that pg_xlog and WAL archive are polled for WAL segments.

commit   : 762bd379a70d626b93d85d89772e47cc355041b3    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 14 Feb 2014 15:15:09 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 14 Feb 2014 15:15:09 +0200    

Click here for diff

If there is a WAL segment with same ID but different TLI present in both  
the WAL archive and pg_xlog, prefer the one with higher TLI. Before this  
patch, the archive was polled first, for all expected TLIs, and only if no  
file was found was pg_xlog scanned. This was a change in behavior from 9.3,  
which first scanned archive and pg_xlog for the highest TLI, then archive  
and pg_xlog for the next highest TLI and so forth. This patch reverts the  
behavior back to what it was in 9.2.  
  
The reason for this is that if for example you try to do archive recovery  
to timeline 2, which branched off timeline 1, but the WAL for timeline 2 is  
not archived yet, we would replay past the timeline switch point on  
timeline 1 using the archived files, before even looking timeline 2's files  
in pg_xlog  
  
Report and patch by Kyotaro Horiguchi. Backpatch to 9.3 where the behavior  
was changed.  

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

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

commit   : f208fb436b40e08189e40c0602f3d5b9882c6dac    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Feb 2014 18:45:15 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Feb 2014 18:45:15 -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

Separate multixact freezing parameters from xid's

commit   : fb47de2be6e44397ab40508729606697f52702ac    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Feb 2014 19:30:30 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 13 Feb 2014 19:30:30 -0300    

Click here for diff

Previously we were piggybacking on transaction ID parameters to freeze  
multixacts; but since there isn't necessarily any relationship between  
rates of Xid and multixact consumption, this turns out not to be a good  
idea.  
  
Therefore, we now have multixact-specific freezing parameters:  
  
vacuum_multixact_freeze_min_age: when to remove multis as we come across  
them in vacuum (default to 5 million, i.e. early in comparison to Xid's  
default of 50 million)  
  
vacuum_multixact_freeze_table_age: when to force whole-table scans  
instead of scanning only the pages marked as not all visible in  
visibility map (default to 150 million, same as for Xids).  Whichever of  
both which reaches the 150 million mark earlier will cause a whole-table  
scan.  
  
autovacuum_multixact_freeze_max_age: when for cause emergency,  
uninterruptible whole-table scans (default to 400 million, double as  
that for Xids).  This means there shouldn't be more frequent emergency  
vacuuming than previously, unless multixacts are being used very  
rapidly.  
  
Backpatch to 9.3 where multixacts were made to persist enough to require  
freezing.  To avoid an ABI break in 9.3, VacuumStmt has a couple of  
fields in an unnatural place, and StdRdOptions is split in two so that  
the newly added fields can go at the end.  
  
Patch by me, reviewed by Robert Haas, with additional input from Andres  
Freund and Tom Lane.  

M doc/src/sgml/config.sgml
M doc/src/sgml/maintenance.sgml
M doc/src/sgml/ref/create_table.sgml
M src/backend/access/common/reloptions.c
M src/backend/access/transam/multixact.c
M src/backend/access/transam/varsup.c
M src/backend/commands/cluster.c
M src/backend/commands/vacuum.c
M src/backend/commands/vacuumlazy.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/equalfuncs.c
M src/backend/parser/gram.y
M src/backend/postmaster/autovacuum.c
M src/backend/utils/misc/guc.c
M src/backend/utils/misc/postgresql.conf.sample
M src/include/commands/cluster.h
M src/include/commands/vacuum.h
M src/include/nodes/parsenodes.h
M src/include/postmaster/autovacuum.h
M src/include/utils/rel.h

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

commit   : ca1c171817c5518932ce549d138f028f5d4d9398    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Feb 2014 14:24:45 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 13 Feb 2014 14:24:45 -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   : 2d77f16c1d8d942e0391d331dc62f3435a995d20    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Feb 2014 19:09:21 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Feb 2014 19:09:21 -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-9.1.sgml
M doc/src/sgml/release-9.2.sgml
M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-old.sgml

Improve text of stub HISTORY file.

commit   : ed2803bdb94b9b8ad80f0d9cdb5976345a0d2fdb    
  
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   : 23f4ded39c5efdce10b8aea8ad9d926c157ef9d5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Feb 2014 17:50:10 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Feb 2014 17:50:10 -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   : 7190f7a345bb3c8f673cf1ca4171f3e9d2b3f47a    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Feb 2014 14:52:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 12 Feb 2014 14:52:20 -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

Add missing include, required on some platforms

commit   : ca7435033bee9a58bbee27b1fd18b7fac0a94e14    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Wed, 12 Feb 2014 20:04:13 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Wed, 12 Feb 2014 20:04:13 +0100    

Click here for diff

Noted by the buildfarm and Andres Freund  

M src/bin/pg_basebackup/pg_basebackup.c

Kill pg_basebackup background process when exiting

commit   : c90204c605b7e12858e52b6af6efdbf3cb1c1bc4    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sun, 9 Feb 2014 13:10:14 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sun, 9 Feb 2014 13:10:14 +0100    

Click here for diff

If an error occurs in the foreground (backup) process of pg_basebackup,  
and we exit in a controlled way, the background process (streaming  
xlog process) would stay around and keep streaming.  

M src/bin/pg_basebackup/pg_basebackup.c
M src/bin/pg_basebackup/pg_receivexlog.c
M src/bin/pg_basebackup/streamutil.h

doc: Postgres date-style date-only output is ISO

commit   : 8247236c639d08724ed13104c2acf8b322a735f0    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Wed, 12 Feb 2014 11:25:04 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Wed, 12 Feb 2014 11:25:04 -0500    

Click here for diff

Backpatch to 9.3  
  
Report from MauMau  

M doc/src/sgml/datatype.sgml

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

commit   : f1e522696fbc01b5c8a41dbd45d6cbae229be425    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Feb 2014 20:48:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 10 Feb 2014 20:48:12 -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   : 928aec71c497c6775cd53d68f7603ba55ab437c1    
  
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

Avoid printing uninitialized filename variable in verbose mode

commit   : 680baa8d242aa0721ffa11957d2a2d90ee61f3bd    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Sun, 9 Feb 2014 11:54:33 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Sun, 9 Feb 2014 11:54:33 +0100    

Click here for diff

When using verbose mode for pg_basebackup, in tar format sent to  
stdout, we'd print an unitialized buffer as the filename.  
  
Reported by Pontus Lundkvist  

M src/bin/pg_basebackup/pg_basebackup.c

Improve connection-failure error handling in contrib/postgres_fdw.

commit   : eb3d350db3fe89e9f58aa82f6b490e2aa457028f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Feb 2014 21:30:05 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Feb 2014 21:30:05 -0500    

Click here for diff

postgres_fdw tended to say "unknown error" if it tried to execute a command  
on an already-dead connection, because some paths in libpq just return a  
null PGresult for such cases.  Out-of-memory might result in that, too.  
To fix, pass the PGconn to pgfdw_report_error, and look at its  
PQerrorMessage() string if we can't get anything out of the PGresult.  
  
Also, fix the transaction-exit logic to reliably drop a dead connection.  
It was attempting to do that already, but it assumed that only connection  
cache entries with xact_depth > 0 needed to be examined.  The folly in that  
is that if we fail while issuing START TRANSACTION, we'll not have bumped  
xact_depth.  (At least for the case I was testing, this fix masks the  
other problem; but it still seems like a good idea to have the PGconn  
fallback logic.)  
  
Per investigation of bug #9087 from Craig Lucas.  Backpatch to 9.3 where  
this code was introduced.  

M contrib/postgres_fdw/connection.c
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/postgres_fdw.h

commit   : 5203b6a752fedb771edc78e6b7b6b8f548de3032    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 3 Feb 2014 20:10:48 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 3 Feb 2014 20:10:48 -0500    

Click here for diff

Otherwise, the standalone regress_README build gets unhappy.  

M doc/src/sgml/regress.sgml

Fix lexing of U& sequences just before EOF.

commit   : 4c70cb1d341d9f0d53d4bfc31327dd68285586ae    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Feb 2014 19:48:00 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Feb 2014 19:48:00 -0500    

Click here for diff

Commit a5ff502fceadc7c203b0d7a11b45c73f1b421f69 was a brick shy of a load  
in the backend lexer too, not just psql.  Per further testing of bug #9068.  
  
In passing, improve related comments.  

M src/backend/parser/scan.l
M src/bin/psql/psqlscan.l

Fix *-qualification of named parameters in SQL-language functions.

commit   : 641c08041fab8270e23017c27935951c3d080501    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Feb 2014 14:46:54 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 3 Feb 2014 14:46:54 -0500    

Click here for diff

Given a composite-type parameter named x, "$1.*" worked fine, but "x.*"  
not so much.  This has been broken since named parameter references were  
added in commit 9bff0780cf5be2193a5bad0d3df2dbe143085264, so patch back  
to 9.2.  Per bug #9085 from Hardy Falk.  

M src/backend/executor/functions.c
M src/test/regress/expected/rowtypes.out
M src/test/regress/sql/rowtypes.sql

Document a few more regression test hazards.

commit   : 5056607ae3b51b8aff0ca4726edb19db7f72f7a9    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Mon, 3 Feb 2014 10:27:47 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Mon, 3 Feb 2014 10:27:47 -0500    

Click here for diff

Michael Paquier, reviewed by Christian Kruse  

M doc/src/sgml/regress.sgml

In json code, clean up temp memory contexts after processing.

commit   : cdfbb78f041676a3a597365abacb2a503e204baa    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 3 Feb 2014 10:39:13 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Mon, 3 Feb 2014 10:39:13 -0500    

Click here for diff

Craig Ringer.  

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

Switch in psql_scan() must cover all lexer states (except backslash cases).

commit   : 1c97ab9251d288cdc1a2d1759983d4bfa66e630c    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Feb 2014 18:59:38 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sun, 2 Feb 2014 18:59:38 -0500    

Click here for diff

Oversight in commit f7559c0101afa33bfb4e104036ca46adac900111, which changed  
UESCAPE lexing in psql.  Per bug #9068 from Manuel Gómez.  

M src/bin/psql/psqlscan.l

Fix makefile syntax.

commit   : 1670557ab0e494b80ed85da6e53b8304bffe11ee    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 1 Feb 2014 19:52:25 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 1 Feb 2014 19:52:25 -0500    

Click here for diff

M src/interfaces/libpq/Makefile

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

commit   : 9beffdcc3ce0f5724de2c95ca98bbcaad45af1d4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Feb 2014 18:26:58 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Feb 2014 18:26:58 -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   : d7b5a31ce9243248074f1445de9b0ea25895affc    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 1 Feb 2014 16:30:22 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 1 Feb 2014 16:30:22 -0500    

Click here for diff

M src/Makefile.shlib

Fix some more bugs in signal handlers and process shutdown logic.

commit   : 6f1a4077310e97fe32379263918a31b95f85e2ed    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Feb 2014 16:21:00 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 1 Feb 2014 16:21:00 -0500    

Click here for diff

WalSndKill was doing things exactly backwards: it should first clear  
MyWalSnd (to stop signal handlers from touching MyWalSnd->latch),  
then disown the latch, and only then mark the WalSnd struct unused by  
clearing its pid field.  
  
Also, WalRcvSigUsr1Handler and worker_spi_sighup failed to preserve  
errno, which is surely a requirement for any signal handler.  
  
Per discussion of recent buildfarm failures.  Back-patch as far  
as the relevant code exists.  

M contrib/worker_spi/worker_spi.c
M src/backend/replication/walreceiver.c
M src/backend/replication/walsender.c

Don't use deprecated dllwrap on Cygwin.

commit   : 27942baf49eb3a939dde14cb81f254fbdf2b1816    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 1 Feb 2014 16:13:32 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 1 Feb 2014 16:13:32 -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   : 1e9876c3b69491906cfcd542ebc8c79e91df6904    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 1 Feb 2014 15:16:06 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sat, 1 Feb 2014 15:16:06 -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   : 5d807a74bf66ba9fb4f55e49e7c601b0b9804123    
  
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

doc: mention data page checksums in WAL section

commit   : 5dc6cab2d2b92bb066291a28d856d37d53e3a944    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Fri, 31 Jan 2014 19:06:24 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Fri, 31 Jan 2014 19:06:24 -0500    

Click here for diff

Backpatch to 9.3  
  
Adjusted patch from Ian Lawrence Barwick  

M doc/src/sgml/wal.sgml

Fix potential coredump on bad locale value in pg_upgrade.

commit   : c1b242b1646137450860cb80683de27be2d86fae    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Jan 2014 18:10:04 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Jan 2014 18:10:04 -0500    

Click here for diff

Thinko in error report (and a typo in the message text, too).  We're  
failing anyway, but it would be good to print something useful first.  
Noted while reviewing a patch to make pg_upgrade's locale code laxer.  

M contrib/pg_upgrade/check.c

Fix bogus handling of "postponed" lateral quals.

commit   : a4aa854cadc9a8272c08940c93cbaeb3d1c89945    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Jan 2014 14:51:19 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 30 Jan 2014 14:51:19 -0500    

Click here for diff

When pulling a "postponed" qual from a LATERAL subquery up into the quals  
of an outer join, we must make sure that the postponed qual is included  
in those seen by make_outerjoininfo().  Otherwise we might compute a  
too-small min_lefthand or min_righthand for the outer join, leading to  
"JOIN qualification cannot refer to other relations" failures from  
distribute_qual_to_rels.  Subtler errors in the created plan seem possible,  
too, if the extra qual would only affect join ordering constraints.  
  
Per bug #9041 from David Leverton.  Back-patch to 9.3.  

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

docs: add mention of index swapping

commit   : e3ec8015d073e5aef10c2618904b20c07bddd904    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Thu, 30 Jan 2014 12:48:21 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Thu, 30 Jan 2014 12:48:21 -0500    

Click here for diff

Backpatch to 9.3  
  
Greg Smith  

M doc/src/sgml/maintenance.sgml
M doc/src/sgml/ref/create_index.sgml

Fix unsafe references to errno within error messaging logic.

commit   : bf8ee6f157fa587f1c71bc9252e53a34bdc4e8be    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jan 2014 20:04:01 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 29 Jan 2014 20:04:01 -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

Enable building with Visual Studion 2013.

commit   : 56c08df55be5a3f12ddc45edcf29b6ecc4111e59    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 26 Jan 2014 09:45:43 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Sun, 26 Jan 2014 09:45:43 -0500    

Click here for diff

Backpatch to 9.3.  
  
Brar Piening.  

M doc/src/sgml/install-windows.sgml
M src/backend/utils/adt/float.c
M src/bin/pg_ctl/pg_ctl.c
M src/include/pg_config.h.win32
M src/include/port/win32.h
M src/tools/msvc/MSBuildProject.pm
M src/tools/msvc/Mkvcbuild.pm
M src/tools/msvc/Solution.pm
M src/tools/msvc/VSObjectFactory.pm

Avoid minor leak in parallel pg_dump

commit   : 8cb90b21af3cc52c21d8a43e2d9f125113ad9f4f    
  
author   : Stephen Frost <sfrost@snowman.net>    
date     : Fri, 24 Jan 2014 15:10:08 -0500    
  
committer: Stephen Frost <sfrost@snowman.net>    
date     : Fri, 24 Jan 2014 15:10:08 -0500    

Click here for diff

During parallel pg_dump, a worker process closing the connection caused  
a minor memory leak (particularly minor as we are likely about to exit  
anyway).  Instead, free the memory in this case prior to returning NULL  
to indicate connection closed.  
  
Spotting by the Coverity scanner.  
  
Back patch to 9.3 where this was introduced.  

M src/bin/pg_dump/parallel.c

Fix bugs in PQhost().

commit   : be5d4997437d185b1b7ca6e53a6e433810aee4f0    
  
author   : Fujii Masao <fujii@postgresql.org>    
date     : Thu, 23 Jan 2014 23:00:30 +0900    
  
committer: Fujii Masao <fujii@postgresql.org>    
date     : Thu, 23 Jan 2014 23:00:30 +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   : d1e3070f0483cef09ebfa91772e70e604f2ad2db    
  
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

commit   : 0950d67ee597797a5a93a00290d52fa7d34cffb7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jan 2014 16:34:31 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 21 Jan 2014 16:34:31 -0500    

Click here for diff

All these constructs generate parse trees consisting of a Const and  
a run-time type coercion (perhaps a FuncExpr or a CoerceViaIO).  Modify  
the raw parse output so that we end up with the original token's location  
attached to the type coercion node while the Const has location -1;  
before, it was the other way around.  This makes no difference in terms  
of what exprLocation() will say about the parse tree as a whole, so it  
should not have any user-visible impact.  The point of changing it is that  
we do not want contrib/pg_stat_statements to treat these constructs as  
replaceable constants.  It will do the right thing if the Const has  
location -1 rather than a valid location.  
  
This is a pretty ugly hack, but then this code is ugly already; we should  
someday replace this translation with special-purpose parse node(s) that  
would allow ruleutils.c to reconstruct the original query text.  
  
(See also commit 5d3fcc4c2e137417ef470d604fee5e452b22f6a7, which also  
hacked location assignment rules for the benefit of pg_stat_statements.)  
  
Back-patch to 9.2 where pg_stat_statements grew the ability to recognize  
replaceable constants.  
  
Kyotaro Horiguchi  

M src/backend/parser/gram.y

Fix inadvertent semantics change in last patch to plug memory leaks.

commit   : 3888b73f9ac9351071f5c2621e2a00ba8012746f    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 21 Jan 2014 11:42:37 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 21 Jan 2014 11:42:37 -0500    

Click here for diff

Commit a5bca4ef034f71175d46462963af2329d22068c2 accidentally changed  
the semantics when the "skipping missing configuration file" is  
emitted, because it forced OK to true instead of leaving the value  
untouched.  
  
Spotted by Tom Lane.  

M src/backend/utils/misc/guc-file.l

Plug more memory leaks when reloading config file.

commit   : efcdb625b3a7e7142b2bd8990afcef380e0c621e    
  
author   : Robert Haas <rhaas@postgresql.org>    
date     : Tue, 21 Jan 2014 09:41:40 -0500    
  
committer: Robert Haas <rhaas@postgresql.org>    
date     : Tue, 21 Jan 2014 09:41:40 -0500    

Click here for diff

Commit 138184adc5f7c60c184972e4d23f8cdb32aed77d plugged some but not  
all of the leaks from commit 2a0c81a12c7e6c5ac1557b0f1f4a581f23fd4ca7.  
This tightens things up some more.  
  
Amit Kapila, per an observation by Tom Lane  

M src/backend/utils/misc/guc-file.l

Allow SET TABLESPACE to database default

commit   : 86e58ae023a93e778cec195b19ffe7ccb01f7038    
  
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   : 586bea6124cd64e495856f97caa612b717cd5de2    
  
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 Hot Standby feedback sending when streaming busily.

commit   : e34acac62e848fc144699d18b33865e1d9474dc3    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 16 Jan 2014 23:05:02 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Thu, 16 Jan 2014 23:05:02 +0200    

Click here for diff

Commit 6f60fdd7015b032bf49273c99f80913d57eac284 accidentally removed a  
call to XLogWalRcvSendHSFeedback() after flushing received WAL to disk.  
The consequence is that when walsender is busy streaming WAL, it doesn't  
send HS feedback messages. One is sent if nothing is received from the  
master for 100ms, but if there's a steady stream of WAL, it never happens.  
  
Backpatch to 9.3.  
  
Andres Freund and Amit Kapila  

M src/backend/replication/walreceiver.c

Improve FILES section of psql reference page.

commit   : 74c32f3455de7bed1a13f1f8b0274a7d43e0e76d    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Jan 2014 19:27:57 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Jan 2014 19:27:57 -0500    

Click here for diff

Primarily, explain where to find the system-wide psqlrc file, per recent  
gripe from John Sutton.  Do some general wordsmithing and improve the  
markup, too.  
  
Also adjust psqlrc.sample so its comments about file location are somewhat  
trustworthy.  (Not sure why we bother with this file when it's empty,  
but whatever.)  
  
Back-patch to 9.2 where the startup file naming scheme was last changed.  

M doc/src/sgml/ref/psql-ref.sgml
M src/bin/psql/psqlrc.sample

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

commit   : ebde6c40148c9f811f7c6d35f67e7ea3ce2d9b34    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Jan 2014 17:34:51 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 14 Jan 2014 17:34:51 -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   : 2b705885719e83cee730d7185da4803ba0e7ebd8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Jan 2014 13:07:13 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 13 Jan 2014 13:07:13 -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   : 50c5770ecdafba7f63c80fa3268467e7df129497    
  
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

Add OVERLAPS to index in the docs.

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

Click here for diff

Per report from Adam Mackler and Jonathan Katz  

M doc/src/sgml/func.sgml

Fix pg_dumpall on pre-8.1 servers

commit   : efb41ba33a2187cce5e6000ca20b4b0844ee68b8    
  
author   : Bruce Momjian <bruce@momjian.us>    
date     : Sun, 12 Jan 2014 22:25:26 -0500    
  
committer: Bruce Momjian <bruce@momjian.us>    
date     : Sun, 12 Jan 2014 22:25:26 -0500    

Click here for diff

rolname did not exist in pg_shadow.  
  
Backpatch to 9.3  
  
Report by Andrew Gierth via IRC  

M src/bin/pg_dump/pg_dumpall.c

Disallow LATERAL references to the target table of an UPDATE/DELETE.

commit   : 27ff4cfe760a79c78eac2948cea67f2ae486cbbf    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Jan 2014 19:03:15 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Jan 2014 19:03:15 -0500    

Click here for diff

On second thought, commit 0c051c90082da0b7e5bcaf9aabcbd4f361137cdc was  
over-hasty: rather than allowing this case, we ought to reject it for now.  
That leaves the field clear for a future feature that allows the target  
table to be re-specified in the FROM (or USING) clause, which will enable  
left-joining the target table to something else.  We can then also allow  
LATERAL references to such an explicitly re-specified target table.  
But allowing them right now will create ambiguities or worse for such a  
feature, and it isn't something we documented 9.3 as supporting.  
  
While at it, add a convenience subroutine to avoid having several copies  
of the ereport for disalllowed-LATERAL-reference cases.  

M src/backend/parser/analyze.c
M src/backend/parser/parse_relation.c
M src/include/parser/parse_node.h
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql

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

commit   : 5bfcc9ec5e78733c5770c17d43c0315e0fcc14b9    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Jan 2014 16:35:30 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 11 Jan 2014 16:35:30 -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   : 36785a21ba6003ddb846cd736170b9c194e97766    
  
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

Accept pg_upgraded tuples during multixact freezing

commit   : a25c2b7c4db3b4542e05d660e55bef5c93fdc32d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 10 Jan 2014 18:03:18 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 10 Jan 2014 18:03:18 -0300    

Click here for diff

The new MultiXact freezing routines introduced by commit 8e9a16ab8f7  
neglected to consider tuples that came from a pg_upgrade'd database; a  
vacuum run that tried to freeze such tuples would die with an error such  
as  
ERROR: MultiXactId 11415437 does no longer exist -- apparent wraparound  
  
To fix, ensure that GetMultiXactIdMembers is allowed to return empty  
multis when the infomask bits are right, as is done in other callsites.  
  
Per trouble report from F-Secure.  
  
In passing, fix a copy&paste bug reported by Andrey Karpov from VIVA64  
from their PVS-Studio static checked, that instead of setting relminmxid  
to Invalid, we were setting relfrozenxid twice.  Not an important  
mistake because that code branch is about relations for which we don't  
use the frozenxid/minmxid values at all in the first place, but seems to  
warrants a fix nonetheless.  

M src/backend/access/heap/heapam.c
M src/backend/catalog/heap.c

Fix descriptor output in ECPG.

commit   : 28fff0ef8b1fadc105aaf28e224e8a5e87866875    
  
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   : 47ac4473ac018f1ec5af5efb2d202646169232eb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Jan 2014 20:18:10 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 8 Jan 2014 20:18:10 -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 pause_at_recovery_target + recovery_target_inclusive combination.

commit   : 3aefff422a9b0fffa7e3a6affdbf491a20c3abaa    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 8 Jan 2014 23:06:03 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Wed, 8 Jan 2014 23:06:03 +0200    

Click here for diff

If pause_at_recovery_target is set, recovery pauses *before* applying the  
target record, even if recovery_target_inclusive is set. If you then  
continue with pg_xlog_replay_resume(), it will apply the target record  
before ending recovery. In other words, if you log in while it's paused  
and verify that the database looks OK, ending recovery changes its state  
again, possibly destroying data that you were tring to salvage with PITR.  
  
Backpatch to 9.1, this has been broken since pause_at_recovery_target was  
added.  

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

Fix bug in determining when recovery has reached consistency.

commit   : 425bef6ee7f210c991f35dff4b3ed6691818c610    
  
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   : a826773bf6a432f418c74fee1f90411adf552d76    
  
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

Fix LATERAL references to target table of UPDATE/DELETE.

commit   : 0a43e5466ca03fce433309c6de2a4272b79c1abb    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Jan 2014 15:25:19 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 7 Jan 2014 15:25:19 -0500    

Click here for diff

I failed to think much about UPDATE/DELETE when implementing LATERAL :-(.  
The implemented behavior ended up being that subqueries in the FROM or  
USING clause (respectively) could access the update/delete target table as  
though it were a lateral reference; which seems fine if they said LATERAL,  
but certainly ought to draw an error if they didn't.  Fix it so you get a  
suitable error when you omit LATERAL.  Per report from Emre Hasegeli.  

M src/backend/parser/analyze.c
M src/backend/parser/parse_clause.c
M src/backend/parser/parse_relation.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql

Move permissions check from do_pg_start_backup to pg_start_backup

commit   : 91c2755fcbd701067702cc889deeddddc6ff7a92    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 7 Jan 2014 17:47:52 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 7 Jan 2014 17:47:52 +0100    

Click here for diff

And the same for do_pg_stop_backup. The code in do_pg_* is not allowed  
to access the catalogs. For manual base backups, the permissions  
check can be handled in the calling function, and for streaming  
base backups only users with the required permissions can get past  
the authentication step in the first place.  
  
Reported by Antonin Houska, diagnosed by Andres Freund  

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

Avoid including tablespaces inside PGDATA twice in base backups

commit   : 0463b9419b4887ddbd2aaaac0c55ee636b4eadd4    
  
author   : Magnus Hagander <magnus@hagander.net>    
date     : Tue, 7 Jan 2014 17:04:40 +0100    
  
committer: Magnus Hagander <magnus@hagander.net>    
date     : Tue, 7 Jan 2014 17:04:40 +0100    

Click here for diff

If a tablespace was crated inside PGDATA it was backed up both as part  
of the PGDATA backup and as the backup of the tablespace. Avoid this  
by skipping any directory inside PGDATA that contains one of the active  
tablespaces.  
  
Dimitri Fontaine and Magnus Hagander  

M src/backend/replication/basebackup.c

Remove bogus -K option from pg_dump.

commit   : 8660f4b759f39f7f98776d6f39001246ad3daf6f    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 6 Jan 2014 12:30:19 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Mon, 6 Jan 2014 12:30:19 +0200    

Click here for diff

I added it to the getopt call by accident in commit  
691e595dd9c7786d37d73ccd327f8c2b6f0dace6.  
  
Amit Kapila  

M src/bin/pg_dump/pg_dump.c

Fix translatability markings in psql, and add defenses against future bugs.

commit   : 341f0bc4954a79555126dabf517a8f6b48b9795f    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jan 2014 16:05:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 4 Jan 2014 16:05:20 -0500    

Click here for diff

Several previous commits have added columns to various \d queries without  
updating their translate_columns[] arrays, leading to potentially incorrect  
translations in NLS-enabled builds.  Offenders include commit 893686762  
(added prosecdef to \df+), c9ac00e6e (added description to \dc+) and  
3b17efdfd (added description to \dC+).  Fix those cases back to 9.3 or  
9.2 as appropriate.  
  
Since this is evidently more easily missed than one would like, in HEAD  
also add an Assert that the supplied array is long enough.  This requires  
an API change for printQuery(), so it seems inappropriate for back  
branches, but presumably all future changes will be tested in HEAD anyway.  
  
In HEAD and 9.3, also clean up a whole lot of sloppiness in the emitted  
SQL for \dy (event triggers): lack of translatability due to failing to  
pass words-to-be-translated through gettext_noop(), inadequate schema  
qualification, and sloppy formatting resulting in unnecessarily ugly  
-E output.  
  
Peter Eisentraut and Tom Lane, per bug #8702 from Sergey Burladyan  

M src/bin/psql/describe.c

Handle 5-char filenames in SlruScanDirectory

commit   : 948a3dfbb79a7e63e3bf31253837fa723f36d8c0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 2 Jan 2014 18:17:29 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 2 Jan 2014 18:17:29 -0300    

Click here for diff

Original users of slru.c were all producing 4-digit filenames, so that  
was all that that code was prepared to handle.  Changes to multixact.c  
in the course of commit 0ac5ad5134f made pg_multixact/members create  
5-digit filenames once a certain threshold was reached, which  
SlruScanDirectory wasn't prepared to deal with; in particular,  
5-digit-name files were not removed during truncation.  Change that  
routine to make it aware of those files, and have it process them just  
like any others.  
  
Right now, some pg_multixact/members directories will contain a mixture  
of 4-char and 5-char filenames.  A future commit is expected fix things  
so that each slru.c user declares the correct maximum width for the  
files it produces, to avoid such unsightly mixtures.  
  
Noticed while investigating bug #8673 reported by Serge Negodyuck.  

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

Wrap multixact/members correctly during extension

commit   : 03db7945961c449ddd42be883e226bb889270161    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 2 Jan 2014 18:17:07 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 2 Jan 2014 18:17:07 -0300    

Click here for diff

In the 9.2 code for extending multixact/members, the logic was very  
simple because the number of entries in a members page was a proper  
divisor of 2^32, and thus at 2^32 wraparound the logic for page switch  
was identical than at any other page boundary.  In commit 0ac5ad5134f I  
failed to realize this and introduced code that was not able to go over  
the 2^32 boundary.  Fix that by ensuring that when we reach the last  
page of the last segment we correctly zero the initial page of the  
initial segment, using correct uint32-wraparound-safe arithmetic.  
  
Noticed while investigating bug #8673 reported by Serge Negodyuck, as  
diagnosed by Andres Freund.  

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

Handle wraparound during truncation in multixact/members

commit   : f40e79173a9941831dfd28137ac6425e0539f82d    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 2 Jan 2014 18:16:54 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 2 Jan 2014 18:16:54 -0300    

Click here for diff

In pg_multixact/members, relying on modulo-2^32 arithmetic for  
wraparound handling doesn't work all that well.  Because we don't  
explicitely track wraparound of the allocation counter for members, it  
is possible that the "live" area exceeds 2^31 entries; trying to remove  
SLRU segments that are "old" according to the original logic might lead  
to removal of segments still in use.  To fix, have the truncation  
routine use a tailored SlruScanDirectory callback that keeps track of  
the live area in actual use; that way, when the live range exceeds 2^31  
entries, the oldest segments still live will not get removed untimely.  
  
This new SlruScanDir callback needs to take care not to remove segments  
that are "in the future": if new SLRU segments appear while the  
truncation is ongoing, make sure we don't remove them.  This requires  
examination of shared memory state to recheck for false positives, but  
testing suggests that this doesn't cause a problem.  The original coding  
didn't suffer from this pitfall because segments created when truncation  
is running are never considered to be removable.  
  
Per Andres Freund's investigation of bug #8673 reported by Serge  
Negodyuck.  

M src/backend/access/transam/multixact.c
M src/backend/access/transam/slru.c
M src/include/access/slru.h

Do not use an empty hostname.

commit   : 8404037d89537a536f0db7e6c977378ed1017e9e    
  
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

Fix broken support for event triggers as extension members.

commit   : 9a6e2b150fd8e024d638ed4f03d61a3fa26e4165    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Dec 2013 14:00:05 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Dec 2013 14:00:05 -0500    

Click here for diff

CREATE EVENT TRIGGER forgot to mark the event trigger as a member of its  
extension, and pg_dump didn't pay any attention anyway when deciding  
whether to dump the event trigger.  Per report from Moshe Jacobson.  
  
Given the obvious lack of testing here, it's rather astonishing that  
ALTER EXTENSION ADD/DROP EVENT TRIGGER work, but they seem to.  

M src/backend/commands/event_trigger.c
M src/bin/pg_dump/pg_dump.c

Fix alphabetization in catalogs.sgml.

commit   : 140b0626e882316386ed422b160d6435467ca1f6    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Dec 2013 13:27:54 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 30 Dec 2013 13:27:54 -0500    

Click here for diff

Some recent patches seem not to have grasped the concept that the catalogs  
are described in alphabetical order.  

M doc/src/sgml/catalogs.sgml

Don't attempt to limit target database for pg_restore.

commit   : 30c36d8cc0df00216fe712f5cec6445d70e2309c    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Sun, 29 Dec 2013 15:18:22 -0600    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Sun, 29 Dec 2013 15:18:22 -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

Properly detect invalid JSON numbers when generating JSON.

commit   : 7dfd9f6f54de39b6d2d2ce52a2faf7c00310bc9d    
  
author   : Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 27 Dec 2013 17:21:04 -0500    
  
committer: Andrew Dunstan <andrew@dunslane.net>    
date     : Fri, 27 Dec 2013 17:21:04 -0500    

Click here for diff

Instead of looking for characters that aren't valid in JSON numbers, we  
simply pass the output string through the JSON number parser, and if it  
fails the string is quoted. This means among other things that money and  
domains over money will be quoted correctly and generate valid JSON.  
  
Fixes bug #8676 reported by Anderson Cristian da Silva.  
  
Backpatched to 9.2 where JSON generation was introduced.  

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

Fix misplaced right paren bugs in pgstatfuncs.c.

commit   : 28b60aa231c1f5ba89495da4f84564ebd9faeeb4    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 27 Dec 2013 15:40:51 -0600    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Fri, 27 Dec 2013 15:40:51 -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

Fix ANALYZE failure on a column that's a domain over a range.

commit   : 663f8419b6e75b6ebc4c22d10fbe55f133f768e0    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Dec 2013 22:18:12 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 23 Dec 2013 22:18:12 -0500    

Click here for diff

Most other range operations seem to work all right on domains,  
but this one not so much, at least not since commit 918eee0c.  
Per bug #8684 from Brett Neumeier.  

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

Avoid useless palloc during transaction commit

commit   : fd995b3f4fe52ecd45d06f8cb8b9d217298df917    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 20 Dec 2013 12:37:30 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 20 Dec 2013 12:37:30 -0300    

Click here for diff

We can allocate the initial relations-to-drop array when first needed,  
instead of at function entry; this avoids allocating it when the  
function is not going to do anything, which is most of the time.  
  
Backpatch to 9.3, where this behavior was introduced by commit  
279628a0a7cf5.  
  
There's more that could be done here, such as possible reworking of the  
code to avoid having to palloc anything, but that doesn't sound as  
backpatchable as this relatively minor change.  
  
Per complaint from Noah Misch in  
20131031145234.GA621493@tornado.leadboat.com  

M src/backend/catalog/storage.c

Optimize updating a row that's locked by same xid

commit   : 85d3b3c3ac16ea7d8f7b513d8ac7bc2f88bb988f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 19 Dec 2013 16:39:59 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 19 Dec 2013 16:39:59 -0300    

Click here for diff

Updating or locking a row that was already locked by the same  
transaction under the same Xid caused a MultiXact to be created; but  
this is unnecessary, because there's no usefulness in being able to  
differentiate two locks by the same transaction.  In particular, if a  
transaction executed SELECT FOR UPDATE followed by an UPDATE that didn't  
modify columns of the key, we would dutifully represent the resulting  
combination as a multixact -- even though a single key-update is  
sufficient.  
  
Optimize the case so that only the strongest of both locks/updates is  
represented in Xmax.  This can save some Xmax's from becoming  
MultiXacts, which can be a significant optimization.  
  
This missed optimization opportunity was spotted by Andres Freund while  
investigating a bug reported by Oliver Seemann in message  
CANCipfpfzoYnOz5jj=UZ70_R=CwDHv36dqWSpwsi27vpm1z5sA@mail.gmail.com  
and also directly as a performance regression reported by Dong Ye in  
message  
d54b8387.000012d8.00000010@YED-DEVD1.vmware.com  
Reportedly, this patch fixes the performance regression.  
  
Since the missing optimization was reported as a significant performance  
regression from 9.2, backpatch to 9.3.  
  
Andres Freund, tweaked by Álvaro Herrera  

M src/backend/access/heap/heapam.c

Don't ignore tuple locks propagated by our updates

commit   : db1014bc46de21a6de1751b807ea084e607104ad    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 18 Dec 2013 13:31:27 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Wed, 18 Dec 2013 13:31:27 -0300    

Click here for diff

If a tuple was locked by transaction A, and transaction B updated it,  
the new version of the tuple created by B would be locked by A, yet  
visible only to B; due to an oversight in HeapTupleSatisfiesUpdate, the  
lock held by A wouldn't get checked if transaction B later deleted (or  
key-updated) the new version of the tuple.  This might cause referential  
integrity checks to give false positives (that is, allow deletes that  
should have been rejected).  
  
This is an easy oversight to have made, because prior to improved tuple  
locks in commit 0ac5ad5134f it wasn't possible to have tuples created by  
our own transaction that were also locked by remote transactions, and so  
locks weren't even considered in that code path.  
  
It is recommended that foreign keys be rechecked manually in bulk after  
installing this update, in case some referenced rows are missing with  
some referencing row remaining.  
  
Per bug reported by Daniel Wood in  
CAPweHKe5QQ1747X2c0tA=5zf4YnS2xcvGf13Opd-1Mq24rF1cQ@mail.gmail.com  

M src/backend/access/transam/multixact.c
M src/backend/utils/time/tqual.c
M src/include/access/multixact.h
A src/test/isolation/expected/propagate-lock-delete.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/propagate-lock-delete.spec

Rework tuple freezing protocol

commit   : 8e9a16ab8f7f0e5813644975cc3f336e5b064b6e    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 16 Dec 2013 11:29:51 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Mon, 16 Dec 2013 11:29:51 -0300    

Click here for diff

Tuple freezing was broken in connection to MultiXactIds; commit  
8e53ae025de9 tried to fix it, but didn't go far enough.  As noted by  
Noah Misch, freezing a tuple whose Xmax is a multi containing an aborted  
update might cause locks in the multi to go ignored by later  
transactions.  This is because the code depended on a multixact above  
their cutoff point not having any lock-only member older than the cutoff  
point for Xids, which is easily defeated in READ COMMITTED transactions.  
  
The fix for this involves creating a new MultiXactId when necessary.  
But this cannot be done during WAL replay, and moreover multixact  
examination requires using CLOG access routines which are not supposed  
to be used during WAL replay either; so tuple freezing cannot be done  
with the old freeze WAL record.  Therefore, separate the freezing  
computation from its execution, and change the WAL record to carry all  
necessary information.  At WAL replay time, it's easy to re-execute  
freezing because we don't need to re-compute the new infomask/Xmax  
values but just take them from the WAL record.  
  
While at it, restructure the coding to ensure all page changes occur in  
a single critical section without much room for failures.  The previous  
coding wasn't using a critical section, without any explanation as to  
why this was acceptable.  
  
In replication scenarios using the 9.3 branch, standby servers must be  
upgraded before their master, so that they are prepared to deal with the  
new WAL record once the master is upgraded; failure to do so will cause  
WAL replay to die with a PANIC message.  Later upgrade of the standby  
will allow the process to continue where it left off, so there's no  
disruption of the data in the standby in any case.  Standbys know how to  
deal with the old WAL record, so it's okay to keep the master running  
the old code for a while.  
  
In master, the old freeze WAL record is gone, for cleanliness' sake;  
there's no compatibility concern there.  
  
Backpatch to 9.3, where the original bug was introduced and where the  
previous fix was backpatched.  
  
Álvaro Herrera and Andres Freund  

M src/backend/access/heap/heapam.c
M src/backend/access/rmgrdesc/heapdesc.c
M src/backend/access/transam/multixact.c
M src/backend/commands/vacuumlazy.c
M src/include/access/heapam_xlog.h
M src/include/access/multixact.h

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

commit   : 8122e6f85a77872f9c67ed384398244e95c1e8e9    
  
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

Fix inherited UPDATE/DELETE with UNION ALL subqueries.

commit   : 324577f39bc8738ed0ec24c36c5cb2c2f81ec660    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 14 Dec 2013 17:33:56 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Sat, 14 Dec 2013 17:33:56 -0500    

Click here for diff

Fix an oversight in commit b3aaf9081a1a95c245fd605dcf02c91b3a5c3a29: we do  
indeed need to process the planner's append_rel_list when copying RTE  
subqueries, because if any of them were flattenable UNION ALL subqueries,  
the append_rel_list shows which subquery RTEs were pulled up out of which  
other ones.  Without this, UNION ALL subqueries aren't correctly inserted  
into the update plans for inheritance child tables after the first one,  
typically resulting in no update happening for those child table(s).  
Per report from Victor Yegorov.  
  
Experimentation with this case also exposed a fault in commit  
a7b965382cf0cb30aeacb112572718045e6d4be7: if an inherited UPDATE/DELETE  
was proven totally dummy by constraint exclusion, we might arrive at  
add_rtes_to_flat_rtable with root->simple_rel_array being NULL.  This  
should be interpreted as not having any RelOptInfos.  I chose to code  
the guard as a check against simple_rel_array_size, so as to also  
provide some protection against indexing off the end of the array.  
  
Back-patch to 9.2 where the faulty code was added.  

M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/plan/setrefs.c
M src/test/regress/expected/inherit.out
M src/test/regress/sql/inherit.sql

Fix typo

commit   : eeb811c454819740ba211c1a85682771ce2a4af0    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 13 Dec 2013 17:26:58 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 13 Dec 2013 17:26:58 -0300    

Click here for diff

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

Rework MultiXactId cache code

commit   : 0bc00363b9b1d5ee44a0b25ed2dfc83f81e68258    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 13 Dec 2013 17:16:25 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Fri, 13 Dec 2013 17:16:25 -0300    

Click here for diff

The original performs too poorly; in some scenarios it shows way too  
high while profiling.  Try to make it a bit smarter to avoid excessive  
cosst.  In particular, make it have a maximum size, and have entries be  
sorted in LRU order; once the max size is reached, evict the oldest  
entry to avoid it from growing too large.  
  
Per complaint from Andres Freund in connection with new tuple freezing  
code.  

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

Add HOLD/RESUME_INTERRUPTS in HandleCatchupInterrupt/HandleNotifyInterrupt.

commit   : 0cfc67bf4f39770e89c0b99f0bb99effdfc80b60    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Dec 2013 14:05:16 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Dec 2013 14:05:16 -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

Don't let timeout interrupts happen unless ImmediateInterruptOK is set.

commit   : 478af9b79770da43a2d89fcc5872d09a2d8731f8    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Dec 2013 11:50:15 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Fri, 13 Dec 2013 11:50:15 -0500    

Click here for diff

Serious oversight in commit 16e1b7a1b7f7ffd8a18713e83c8cd72c9ce48e07:  
we should not allow an interrupt to take control away from mainline code  
except when ImmediateInterruptOK is set.  Just to be safe, let's adopt  
the same save-clear-restore dance that's been used for many years in  
HandleCatchupInterrupt and HandleNotifyInterrupt, so that nothing bad  
happens if a timeout handler invokes code that tests or even manipulates  
ImmediateInterruptOK.  
  
Per report of "stuck spinlock" failures from Christophe Pettus, though  
many other symptoms are possible.  Diagnosis by Andres Freund.  

M src/backend/utils/misc/timeout.c

Fix WAL-logging of setting the visibility map bit.

commit   : 615299cf63a730f9e170532c4782cd5a4a06a7ac    
  
author   : Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 13 Dec 2013 13:52:47 +0200    
  
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>    
date     : Fri, 13 Dec 2013 13:52:47 +0200    

Click here for diff

The operation that removes the remaining dead tuples from the page must  
be WAL-logged before the setting of the VM bit. Otherwise, if you replay  
the WAL to between those two records, you end up with the VM bit set, but  
the dead tuples are still there.  
  
Backpatch to 9.3, where this bug was introduced.  

M src/backend/commands/vacuumlazy.c

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

commit   : b57947aa9cacaac58b4baa7b30306ccf803d6c88    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Dec 2013 12:39:54 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 12 Dec 2013 12:39:54 -0500    

Click here for diff

Pointed out by Gianni Ciolli.  

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

Fix progress logging when scale factor is large.

commit   : 27902bc9164d227cbdf1242de218edeaf8cd9f7f    
  
author   : Tatsuo Ishii <ishii@postgresql.org>    
date     : Thu, 12 Dec 2013 19:01:01 +0900    
  
committer: Tatsuo Ishii <ishii@postgresql.org>    
date     : Thu, 12 Dec 2013 19:01:01 +0900    

Click here for diff

Integer overflow showed minus percent and minus remaining time something like this.  
  239300000 of 3800000000 tuples (-48%) done (elapsed 226.86 s, remaining -696.10 s).  

M contrib/pgbench/pgbench.c

Tweak placement of explicit ANALYZE commands in the regression tests.

commit   : 6dc71a7e773c55cff72fc1f9c960287480ad3130    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Dec 2013 15:08:35 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Wed, 11 Dec 2013 15:08:35 -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/aggregates.out
M src/test/regress/expected/alter_table.out
M src/test/regress/expected/arrays.out
M src/test/regress/expected/create_index.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/aggregates.sql
M src/test/regress/sql/alter_table.sql
M src/test/regress/sql/arrays.sql
M src/test/regress/sql/create_index.sql
M src/test/regress/sql/join.sql

Add table name to VACUUM statement in matview.c.

commit   : 80811f94ebd7d47510e7c4aafc382babd3826d39    
  
author   : Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 11 Dec 2013 08:56:02 -0600    
  
committer: Kevin Grittner <kgrittn@postgresql.org>    
date     : Wed, 11 Dec 2013 08:56:02 -0600    

Click here for diff

The test only needs the one table to be vacuumed.  Vacuuming the  
database may affect other tests.  
  
Per gripe from Tom Lane.  Back-patch to 9.3, where the test was  
was added.  

M src/test/regress/expected/matview.out
M src/test/regress/sql/matview.sql

commit   : 9d2e07fecd4bd37fc9e231bd706bc0c9ce0f17a7    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Dec 2013 16:10:20 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Tue, 10 Dec 2013 16:10:20 -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   : 0ec530625f1cc0a17d975f925fed5d3ab469c6f8    
  
author   : Joe Conway <mail@joeconway.com>    
date     : Sat, 7 Dec 2013 17:00:10 -0800    
  
committer: Joe Conway <mail@joeconway.com>    
date     : Sat, 7 Dec 2013 17:00:10 -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

Fix improper abort during update chain locking

commit   : 2dcc48c35af5305fba0d8cb5e31fa0c25f52d13f    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 5 Dec 2013 17:47:51 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 5 Dec 2013 17:47:51 -0300    

Click here for diff

In 247c76a98909, I added some code to do fine-grained checking of  
MultiXact status of locking/updating transactions when traversing an  
update chain.  There was a thinko in that patch which would have the  
traversing abort, that is return HeapTupleUpdated, when the other  
transaction is a committed lock-only.  In this case we should ignore it  
and return success instead.  Of course, in the case where there is a  
committed update, HeapTupleUpdated is the correct return value.  
  
A user-visible symptom of this bug is that in REPEATABLE READ and  
SERIALIZABLE transaction isolation modes spurious serializability errors  
can occur:  
  ERROR:  could not serialize access due to concurrent update  
  
In order for this to happen, there needs to be a tuple that's key-share-  
locked and also updated, and the update must abort; a subsequent  
transaction trying to acquire a new lock on that tuple would abort with  
the above error.  The reason is that the initial FOR KEY SHARE is seen  
as committed by the new locking transaction, which triggers this bug.  
(If the UPDATE commits, then the serialization error is correctly  
reported.)  
  
When running a query in READ COMMITTED mode, what happens is that the  
locking is aborted by the HeapTupleUpdated return value, then  
EvalPlanQual fetches the newest version of the tuple, which is then the  
only version that gets locked.  (The second time the tuple is checked  
there is no misbehavior on the committed lock-only, because it's not  
checked by the code that traverses update chains; so no bug.) Only the  
newest version of the tuple is locked, not older ones, but this is  
harmless.  
  
The isolation test added by this commit illustrates the desired  
behavior, including the proper serialization errors that get thrown.  
  
Backpatch to 9.3.  

M src/backend/access/heap/heapam.c
A src/test/isolation/expected/multixact-no-forget.out
A src/test/isolation/expected/multixact-no-forget_1.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/multixact-no-forget.spec

Clear retry flags properly in replacement OpenSSL sock_write function.

commit   : 2a6e1a55454bababea78af2db2f95c6eb7dd8ed5    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Dec 2013 12:48:31 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Thu, 5 Dec 2013 12:48:31 -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

Avoid resetting Xmax when it's a multi with an aborted update

commit   : c6cd27e36b9c58ceda8582ba81e37b6f9ad87d59    
  
author   : Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 5 Dec 2013 12:21:55 -0300    
  
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>    
date     : Thu, 5 Dec 2013 12:21:55 -0300    

Click here for diff

HeapTupleSatisfiesUpdate can very easily "forget" tuple locks while  
checking the contents of a multixact and finding it contains an aborted  
update, by setting the HEAP_XMAX_INVALID bit.  This would lead to  
concurrent transactions not noticing any previous locks held by  
transactions that might still be running, and thus being able to acquire  
subsequent locks they wouldn't be normally able to acquire.  
  
This bug was introduced in commit 1ce150b7bb; backpatch this fix to 9.3,  
like that commit.  
  
This change reverts the change to the delete-abort-savept isolation test  
in 1ce150b7bb, because that behavior change was caused by this bug.  
  
Noticed by Andres Freund while investigating a different issue reported  
by Noah Misch.  

M src/backend/utils/time/tqual.c
M src/test/isolation/expected/delete-abort-savept.out

Fix full-page writes of internal GIN pages.

commit   : 8fd04cb32867e35a6a88860cc2c735f891393402    
  
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

Fix crash in assign_collations_walker for EXISTS with empty SELECT list.

commit   : b44ae4893db20233b470e41916b67799a1738bf4    
  
author   : Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Dec 2013 20:28:49 -0500    
  
committer: Tom Lane <tgl@sss.pgh.pa.us>    
date     : Mon, 2 Dec 2013 20:28:49 -0500    

Click here for diff

We (I think I, actually) forgot about this corner case while coding  
collation resolution.  Per bug #8648 from Arjen Nienhuis.  

M src/backend/parser/parse_collate.c
M src/test/regress/expected/subselect.out
M src/test/regress/sql/subselect.sql