Stamp 9.3.21.
commit : 0a0ee721f8190f8e6e633aa959bf9801932bd361
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Feb 2018 16:08:57 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Feb 2018 16:08:57 -0500
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 : 01b2db1cd6673a94cc5249aa25b34e7d98535c11
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Feb 2018 14:43:41 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Feb 2018 14:43:41 -0500
Security: CVE-2018-1052, CVE-2018-1053
M doc/src/sgml/release-9.3.sgml
Translation updates
commit : 790808b37736798c4da776bd91d8440d0e856e11
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 5 Feb 2018 12:48:55 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 5 Feb 2018 12:48:55 -0500
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 51111d1489f84240611b69adf3f4cc0b0501e41e
M src/backend/po/de.po
M src/backend/po/fr.po
M src/backend/po/it.po
M src/backend/po/ru.po
M src/bin/initdb/po/fr.po
M src/bin/initdb/po/it.po
M src/bin/pg_basebackup/po/it.po
M src/bin/pg_config/po/it.po
M src/bin/pg_controldata/po/it.po
M src/bin/pg_ctl/po/fr.po
M src/bin/pg_ctl/po/it.po
M src/bin/pg_dump/po/it.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_resetxlog/po/fr.po
M src/bin/pg_resetxlog/po/it.po
M src/bin/psql/po/de.po
M src/bin/psql/po/it.po
M src/bin/psql/po/ru.po
M src/bin/scripts/po/it.po
M src/interfaces/ecpg/ecpglib/po/it.po
M src/interfaces/ecpg/preproc/po/de.po
M src/interfaces/ecpg/preproc/po/it.po
M src/interfaces/ecpg/preproc/po/ru.po
M src/interfaces/libpq/po/it.po
M src/interfaces/libpq/po/ru.po
M src/pl/plperl/po/it.po
M src/pl/plpgsql/src/po/it.po
M src/pl/plpython/po/it.po
M src/pl/tcl/po/it.po
Ensure that all temp files made during pg_upgrade are non-world-readable.
commit : 9c59e48a22aa150c4d63017955328d87bea1cd29
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Feb 2018 10:58:27 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Feb 2018 10:58:27 -0500
pg_upgrade has always attempted to ensure that the transient dump files
it creates are inaccessible except to the owner. However, refactoring
in commit 76a7650c4 broke that for the file containing "pg_dumpall -g"
output; since then, that file was protected according to the process's
default umask. Since that file may contain role passwords (hopefully
encrypted, but passwords nonetheless), this is a particularly unfortunate
oversight. Prudent users of pg_upgrade on multiuser systems would
probably run it under a umask tight enough that the issue is moot, but
perhaps some users are depending only on pg_upgrade's umask changes to
protect their data.
To fix this in a future-proof way, let's just tighten the umask at
process start. There are no files pg_upgrade needs to write at a
weaker security level; and if there were, transiently relaxing the
umask around where they're created would be a safer approach.
Report and patch by Tom Lane; the idea for the fix is due to Noah Misch.
Back-patch to all supported branches.
Security: CVE-2018-1053
M contrib/pg_upgrade/dump.c
M contrib/pg_upgrade/file.c
M contrib/pg_upgrade/pg_upgrade.c
M contrib/pg_upgrade/pg_upgrade.h
Release notes for 10.2, 9.6.7, 9.5.11, 9.4.16, 9.3.21.
commit : b76aa1f5c078f4202006ef59112cd7890f47d979
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Feb 2018 15:13:45 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Feb 2018 15:13:45 -0500
M doc/src/sgml/release-9.3.sgml
doc: in contrib-spi, mention and link to the meaning of SPI
commit : 2d58ef3469e14d8b4f62c6bef98cb7c313ede2cc
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Jan 2018 16:54:33 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 31 Jan 2018 16:54:33 -0500
Also remove outdated comment about SPI subtransactions.
Reported-by: gregory@arenius.com
Discussion: https://postgr.es/m/151726276676.1240.10501743959198501067@wrigleys.postgresql.org
Backpatch-through: 9.3
M doc/src/sgml/contrib-spi.sgml
M doc/src/sgml/spi.sgml
pgcrypto's encrypt() supports AES-128, AES-192, and AES-256
commit : 4ab8ded9fb4e3b28051e994163b90f0ea4946f9b
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 31 Jan 2018 16:28:11 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 31 Jan 2018 16:28:11 -0500
Previously, only 128 was mentioned, but the others are also supported.
Thomas Munro, reviewed by Michael Paquier and extended a bit by me.
Discussion: http://postgr.es/m/CAEepm=1XbBHXYJKofGjnM2Qfz-ZBVqhGU4AqvtgR+Hegy4fdKg@mail.gmail.com
M contrib/pgcrypto/expected/rijndael.out
M contrib/pgcrypto/sql/rijndael.sql
M doc/src/sgml/pgcrypto.sgml
psql documentation fixes
commit : 98e4dce78b5139a1a7935903627498c41f0b2d6a
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 29 Jan 2018 14:04:32 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 29 Jan 2018 14:04:32 -0500
Update the documentation for \pset to mention
columns|linestyle.
Author: Дилян Палаузов <dpa-postgres@aegee.org>
M doc/src/sgml/ref/psql-ref.sgml
M src/bin/psql/help.c
Add stack-overflow guards in set-operation planning.
commit : c03fc84626beca122d4aafd77fe6eb508d98edb7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 28 Jan 2018 13:39:07 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 28 Jan 2018 13:39:07 -0500
create_plan_recurse lacked any stack depth check. This is not per
our normal coding rules, but I'd supposed it was safe because earlier
planner processing is more complex and presumably should eat more
stack. But bug #15033 from Andrew Grossman shows this isn't true,
at least not for queries having the form of a many-thousand-way
INTERSECT stack.
Further testing showed that recurse_set_operations is also capable
of being crashed in this way, since it likewise will recurse to the
bottom of a parsetree before calling any support functions that
might themselves contain any stack checks. However, its stack
consumption is only perhaps a third of create_plan_recurse's.
It's possible that this particular problem with create_plan_recurse can
only manifest in 9.6 and later, since before that we didn't build a Path
tree for set operations. But having seen this example, I now have no
faith in the proposition that create_plan_recurse doesn't need a stack
check, so back-patch to all supported branches.
Discussion: https://postgr.es/m/20180127050845.28812.58244@wrigleys.postgresql.org
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/prep/prepunion.c
Update time zone data files to tzdata release 2018c.
commit : e5e2cc6f8c1d257991804021d64270e544a81297
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 27 Jan 2018 16:42:28 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 27 Jan 2018 16:42:28 -0500
DST law changes in Brazil, Sao Tome and Principe. Historical corrections
for Bolivia, Japan, and South Sudan. The "US/Pacific-New" zone has been
removed (it was only a link to America/Los_Angeles anyway).
M src/timezone/data/tzdata.zi
M src/timezone/known_abbrevs.txt
M src/timezone/tznames/Africa.txt
Teach reparameterize_path() to handle AppendPaths.
commit : b100a5274ffa4f29b4441eb17fe2a909f3074b79
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 23 Jan 2018 16:50:35 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 23 Jan 2018 16:50:35 -0500
If we're inside a lateral subquery, there may be no unparameterized paths
for a particular child relation of an appendrel, in which case we *must*
be able to create similarly-parameterized paths for each other child
relation, else the planner will fail with "could not devise a query plan
for the given query". This means that there are situations where we'd
better be able to reparameterize at least one path for each child.
This calls into question the assumption in reparameterize_path() that
it can just punt if it feels like it. However, the only case that is
known broken right now is where the child is itself an appendrel so that
all its paths are AppendPaths. (I think possibly I disregarded that in
the original coding on the theory that nested appendrels would get folded
together --- but that only happens *after* reparameterize_path(), so it's
not excused from handling a child AppendPath.) Given that this code's been
like this since 9.3 when LATERAL was introduced, it seems likely we'd have
heard of other cases by now if there were a larger problem.
Per report from Elvis Pranskevichus. Back-patch to 9.3.
Discussion: https://postgr.es/m/5981018.zdth1YWmNy@hammer.magicstack.net
M src/backend/optimizer/util/pathnode.c
M src/test/regress/expected/join.out
M src/test/regress/sql/join.sql
doc: simplify intermediate certificate mention in libpq docs
commit : b049ae3a3a3d05f65490097f8fe05ef8354365fd
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 23 Jan 2018 10:18:21 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 23 Jan 2018 10:18:21 -0500
Backpatch-through: 9.3
M doc/src/sgml/libpq.sgml
Make pg_dump's ACL, sec label, and comment entries reliably identifiable.
commit : ef115621c45c891c5e8d8ac396f513721fdbd610
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 22 Jan 2018 12:06:19 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 22 Jan 2018 12:06:19 -0500
_tocEntryRequired() expects that it can identify ACL, SECURITY LABEL,
and COMMENT TOC entries that are for large objects by seeing whether
the tag for them starts with "LARGE OBJECT ". While that works fine
for actual large objects, which are indeed tagged that way, it's
subject to false positives unless every such entry's tag starts with an
appropriate type ID. And in fact it does not work for ACLs, because
up to now we customarily tagged those entries with just the bare name
of the object. This means that an ACL for an object named
"LARGE OBJECT something" would be misclassified as data not schema,
with undesirable results in a schema-only or data-only dump ---
although pg_upgrade seems unaffected, due to the special case for
binary-upgrade mode further down in _tocEntryRequired().
We can fix this by changing all the dumpACL calls to use the label
strings already in use for comments and security labels, which do
follow the convention of starting with an object type indicator.
Well, mostly they follow it. dumpDatabase() got it wrong, using
just the bare database name for those purposes, so that a database
named "LARGE OBJECT something" would similarly be subject to having
its comment or security label dropped or included when not wanted.
Bring that into line too. (Note that up to now, database ACLs have
not been processed by pg_dump, so that this issue doesn't affect them.)
_tocEntryRequired() itself is not free of fault: it was overly liberal
about matching object tags to "LARGE OBJECT " in binary-upgrade mode.
This looks like it is probably harmless because there would be no data
component to strip anyway in that mode, but at best it's trouble
waiting to happen, so tighten that up too.
The possible misclassification of SECURITY LABEL entries for databases is
in principle a security problem, but the opportunities for actual exploits
seem too narrow to be interesting. The other cases seem like just bugs,
since an object owner can change its ACL or comment for himself, he needn't
try to trick someone else into doing it by choosing a strange name.
This has been broken since per-large-object TOC entries were introduced
in 9.0, so back-patch to all supported branches.
Discussion: https://postgr.es/m/21714.1516553459@sss.pgh.pa.us
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_dump.c
doc: update intermediate certificate instructions
commit : 0253f80a7a24b1b6489a2c77562588237706d367
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 20 Jan 2018 21:47:02 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 20 Jan 2018 21:47:02 -0500
Document how to properly create root and intermediate certificates using
v3_ca extensions and where to place intermediate certificates so they
are properly transferred to the remote side with the leaf certificate to
link to the remote root certificate. This corrects docs that used to
say that intermediate certificates must be stored with the root
certificate.
Also add instructions on how to create root, intermediate, and leaf
certificates.
Discussion: https://postgr.es/m/20180116002238.GC12724@momjian.us
Reviewed-by: Michael Paquier
Backpatch-through: 9.3
M doc/src/sgml/libpq.sgml
M doc/src/sgml/runtime.sgml
Fix StoreCatalogInheritance1 to use 32bit inhseqno
commit : 9a215fb4b5ec67b481b3ad742e1419fa3f466598
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 19 Jan 2018 10:15:08 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 19 Jan 2018 10:15:08 -0300
For no apparent reason, this function was using a 16bit-wide inhseqno
value, rather than the correct 32 bit width which is what is stored in
the pg_inherits catalog. This becomes evident if you try to create a
table with more than 65535 parents, because this error appears:
ERROR: duplicate key value violates unique constraint «pg_inherits_relid_seqno_index»
DETAIL: Key (inhrelid, inhseqno)=(329371, 0) already exists.
Needless to say, having so many parents is an uncommon situations, which
explains why this error has never been reported despite being having
been introduced with the Postgres95 1.01 sources in commit d31084e9d111:
https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/commands/creatinh.c;hb=d31084e9d111#l349
Backpatch all the way back.
David Rowley noticed this while reviewing a patch of mine.
Discussion: https://postgr.es/m/CAKJS1f8Dn7swSEhOWwzZzssW7747YB=2Hi+T7uGud40dur69-g@mail.gmail.com
M src/backend/commands/tablecmds.c
Cope with indicator arrays that do not have the correct length.
commit : a0f5890a64e8a5d593b762183682b73ea72f2fe1
author : Michael Meskes <meskes@postgresql.org>
date : Sat, 13 Jan 2018 14:56:49 +0100
committer: Michael Meskes <meskes@postgresql.org>
date : Sat, 13 Jan 2018 14:56:49 +0100
Patch by: "Rader, David" <davidr@openscg.com>
M src/interfaces/ecpg/preproc/type.c
Avoid unnecessary failure in SELECT concurrent with ALTER NO INHERIT.
commit : 4e71700584de1e7db6b05257f61dc643e4bea2bf
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 12 Jan 2018 15:46:38 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 12 Jan 2018 15:46:38 -0500
If a query against an inheritance tree runs concurrently with an ALTER
TABLE that's disinheriting one of the tree members, it's possible to get
a "could not find inherited attribute" error because after obtaining lock
on the removed member, make_inh_translation_list sees that its columns
have attinhcount=0 and decides they aren't the columns it's looking for.
An ideal fix, perhaps, would avoid including such a just-removed member
table in the query at all; but there seems no way to accomplish that
without adding expensive catalog rechecks or creating a likelihood of
deadlocks. Instead, let's just drop the check on attinhcount. In this
way, a query that's included a just-disinherited child will still
succeed, which is not a completely unreasonable behavior.
This problem has existed for a long time, so back-patch to all supported
branches. Also add an isolation test verifying related behaviors.
Patch by me; the new isolation test is based on Kyotaro Horiguchi's work.
Discussion: https://postgr.es/m/20170626.174612.23936762.horiguchi.kyotaro@lab.ntt.co.jp
M src/backend/optimizer/prep/prepunion.c
A src/test/isolation/expected/alter-table-4.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/alter-table-4.spec
Fix sample INSTR() functions in the plpgsql documentation.
commit : 45bfef7fbae98a076c86e23f3b59eab81e3cb70b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 10 Jan 2018 17:13:29 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 10 Jan 2018 17:13:29 -0500
These functions are stated to be Oracle-compatible, but they weren't.
Yugo Nagata noticed that while our code returns zero for a zero or
negative fourth parameter (occur_index), Oracle throws an error.
Further testing by me showed that there was also a discrepancy in the
interpretation of a negative third parameter (beg_index): Oracle thinks
that a negative beg_index indicates the last place where the target
substring can *begin*, whereas our code thinks it is the last place
where the target can *end*.
Adjust the sample code to behave like Oracle in both these respects.
Also change it to be a CDATA[] section, simplifying copying-and-pasting
out of the documentation source file. And fix minor problems in the
introductory comment, which wasn't very complete or accurate.
Back-patch to all supported branches. Although this patch only touches
documentation, we should probably call it out as a bug fix in the next
minor release notes, since users who have adopted the functions will
likely want to update their versions.
Yugo Nagata and Tom Lane
Discussion: https://postgr.es/m/20171229191705.c0b43a8c.nagata@sraoss.co.jp
M doc/src/sgml/plpgsql.sgml
Change some bogus PageGetLSN calls to BufferGetLSNAtomic
commit : 469fa9ad6d0564b7252e89726533c0b7ccb2c4ec
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 9 Jan 2018 15:54:38 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 9 Jan 2018 15:54:38 -0300
As src/backend/access/transam/README says, PageGetLSN may only be called
by processes holding either exclusive lock on buffer, or a shared lock
on buffer plus buffer header lock. Therefore any place that only holds
a shared buffer lock must use BufferGetLSNAtomic instead of PageGetLSN,
which internally obtains buffer header lock prior to reading the LSN.
A few callsites failed to comply with this rule. This was detected by
running all tests under a new (not committed) assertion that verifies
PageGetLSN locking contract. All but one of the callsites that failed
the assertion are fixed by this patch. Remaining callsites were
inspected manually and determined not to need any change.
The exception (unfixed callsite) is in TestForOldSnapshot, which only
has a Page argument, making it impossible to access the corresponding
Buffer from it. Fixing that seems a much larger patch that will have to
be done separately; and that's just as well, since it was only
introduced in 9.6 and other bugs are much older.
Some of these bugs are ancient; backpatch all the way back to 9.3.
Authors: Jacob Champion, Asim Praveen, Ashwin Agrawal
Reviewed-by: Michaël Paquier
Discussion: https://postgr.es/m/CABAq_6GXgQDVu3u12mK9O5Xt5abBZWQ0V40LZCE+oUf95XyNFg@mail.gmail.com
M src/backend/access/gist/gist.c
M src/backend/access/gist/gistvacuum.c
Fix use of config-specific libraries for Windows OpenSSL
commit : 5404145c5ad4b86865c2030f0dbba52686e80c21
author : Andrew Dunstan <andrew@dunslane.net>
date : Wed, 3 Jan 2018 15:26:39 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Wed, 3 Jan 2018 15:26:39 -0500
Commit 614350a3 allowed for an different builds of OpenSSL libraries on
Windows, but ignored the fact that the alternative builds don't have
config-specific libraries. This patch fixes the Solution file to ask for
the correct libraries.
per offline discussions with Leonardo Cecchi and Marco Nenciarini,
Backpatch to all live branches.
M src/tools/msvc/Solution.pm
Update copyright for 2018
commit : 9173695b616665592d3dc62a72ef5cbb859dca65
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 2 Jan 2018 23:30:12 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 2 Jan 2018 23:30:12 -0500
Backpatch-through: certain files through 9.3
M COPYRIGHT
M doc/src/sgml/legal.sgml
Perform a lot more sanity checks when freezing tuples.
commit : 4800f16a7ad08fe4145cdbbfedb9f63fdc282e28
author : Andres Freund <andres@anarazel.de>
date : Mon, 13 Nov 2017 18:45:47 -0800
committer: Andres Freund <andres@anarazel.de>
date : Mon, 13 Nov 2017 18:45:47 -0800
The previous commit has shown that the sanity checks around freezing
aren't strong enough. Strengthening them seems especially important
because the existance of the bug has caused corruption that we don't
want to make even worse during future vacuum cycles.
The errors are emitted with ereport rather than elog, despite being
"should never happen" messages, so a proper error code is emitted. To
avoid superflous translations, mark messages as internal.
Author: Andres Freund and Alvaro Herrera
Reviewed-By: Alvaro Herrera, Michael Paquier
Discussion: https://postgr.es/m/20171102112019.33wb7g5wp4zpjelu@alap3.anarazel.de
Backpatch: 9.3-
M src/backend/access/heap/heapam.c
M src/backend/access/heap/rewriteheap.c
M src/backend/commands/vacuumlazy.c
M src/include/access/heapam.h
M src/include/access/heapam_xlog.h
Fix pruning of locked and updated tuples.
commit : 387abe8707745f1f136c8942ac7d72cf4601d69e
author : Andres Freund <andres@anarazel.de>
date : Fri, 3 Nov 2017 07:52:29 -0700
committer: Andres Freund <andres@anarazel.de>
date : Fri, 3 Nov 2017 07:52:29 -0700
Previously it was possible that a tuple was not pruned during vacuum,
even though its update xmax (i.e. the updating xid in a multixact with
both key share lockers and an updater) was below the cutoff horizon.
As the freezing code assumed, rightly so, that that's not supposed to
happen, xmax would be preserved (as a member of a new multixact or
xmax directly). That causes two problems: For one the tuple is below
the xmin horizon, which can cause problems if the clog is truncated or
once there's an xid wraparound. The bigger problem is that that will
break HOT chains, which in turn can lead two to breakages: First,
failing index lookups, which in turn can e.g lead to constraints being
violated. Second, future hot prunes / vacuums can end up making
invisible tuples visible again. There's other harmful scenarios.
Fix the problem by recognizing that tuples can be DEAD instead of
RECENTLY_DEAD, even if the multixactid has alive members, if the
update_xid is below the xmin horizon. That's safe because newer
versions of the tuple will contain the locking xids.
A followup commit will harden the code somewhat against future similar
bugs and already corrupted data.
Author: Andres Freund, with changes by Alvaro Herrera
Reported-By: Daniel Wood
Analyzed-By: Andres Freund, Alvaro Herrera, Robert Haas, Peter
Geoghegan, Daniel Wood, Yi Wen Wong, Michael Paquier
Reviewed-By: Alvaro Herrera, Robert Haas, Michael Paquier
Discussion:
https://postgr.es/m/E5711E62-8FDF-4DCA-A888-C200BF6B5742@amazon.com
https://postgr.es/m/20171102112019.33wb7g5wp4zpjelu@alap3.anarazel.de
Backpatch: 9.3-
M src/backend/utils/time/tqual.c
M src/test/isolation/expected/freeze-the-dead.out
M src/test/isolation/isolation_schedule
M src/test/isolation/specs/freeze-the-dead.spec
Backport addition of rs_old_rel to rewriteheap's state.
commit : 152a56905658b7d9f8927f41f000abac718e1a39
author : Andres Freund <andres@anarazel.de>
date : Thu, 14 Dec 2017 16:50:31 -0800
committer: Andres Freund <andres@anarazel.de>
date : Thu, 14 Dec 2017 16:50:31 -0800
Originally part of b89e151054a05f0f6d356ca52e3b725dd0505e53, the
introduction of logical decoding, this is required to backport a
commit introducing error checks defending against recent bugs.
It's possible that extensions calls begin_heap_rewrite(), but it seems
highly unlikely. But if so, they'd break.
Author: Andres Freund
Discussion: https://postgr.es/m/20171215010029.3dxx56vjlymudvwo@alap3.anarazel.de
M src/backend/access/heap/rewriteheap.c
M src/backend/commands/cluster.c
M src/include/access/rewriteheap.h
Fix corner-case coredump in _SPI_error_callback().
commit : d5f767c136d2531ad58053498c7236706779f692
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 11 Dec 2017 16:33:20 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 11 Dec 2017 16:33:20 -0500
I noticed that _SPI_execute_plan initially sets spierrcontext.arg = NULL,
and only fills it in some time later. If an error were to happen in
between, _SPI_error_callback would try to dereference the null pointer.
This is unlikely --- there's not much between those points except
push-snapshot calls --- but it's clearly not impossible. Tweak the
callback to do nothing if the pointer isn't set yet.
It's been like this for awhile, so back-patch to all supported branches.
M src/backend/executor/spi.c
MSVC 2012+: Permit linking to 32-bit, MinGW-built libraries.
commit : 70dc7ad584f50f1c02d4d4a67bdf77b378017fa9
author : Noah Misch <noah@leadboat.com>
date : Sat, 9 Dec 2017 00:58:55 -0800
committer: Noah Misch <noah@leadboat.com>
date : Sat, 9 Dec 2017 00:58:55 -0800
Notably, this permits linking to the 32-bit Perl binaries advertised on
perl.org, namely Strawberry Perl and ActivePerl. This has a side effect
of permitting linking to binaries built with obsolete MSVC versions.
By default, MSVC 2012 and later require a "safe exception handler table"
in each binary. MinGW-built, 32-bit DLLs lack the relevant exception
handler metadata, so linking to them failed with error LNK2026. Restore
the semantics of MSVC 2010, which omits the table from a given binary if
some linker input lacks metadata. This has no effect on 64-bit builds
or on MSVC 2010 and earlier. Back-patch to 9.3 (all supported
versions).
Reported by Victor Wagner.
Discussion: https://postgr.es/m/20160326154321.7754ab8f@wagner.wagner.home
M src/tools/msvc/MSBuildProject.pm
MSVC: Test whether 32-bit Perl needs -D_USE_32BIT_TIME_T.
commit : 1886899420cefea32f3cd4ca38ef5187634e7d8e
author : Noah Misch <noah@leadboat.com>
date : Fri, 8 Dec 2017 18:06:05 -0800
committer: Noah Misch <noah@leadboat.com>
date : Fri, 8 Dec 2017 18:06:05 -0800
Commits 5a5c2feca3fd858e70ea348822595547e6fa6c15 and
b5178c5d08ca59e30f9d9428fa6fdb2741794e65 introduced support for modern
MSVC-built, 32-bit Perl, but they broke use of MinGW-built, 32-bit Perl
distributions like Strawberry Perl and modern ActivePerl. Perl has no
robust means to report whether it expects a -D_USE_32BIT_TIME_T ABI, so
test this. Back-patch to 9.3 (all supported versions).
The chief alternative was a heuristic of adding -D_USE_32BIT_TIME_T when
$Config{gccversion} is nonempty. That banks on every gcc-built Perl
using the same ABI. gcc could change its default ABI the way MSVC once
did, and one could build Perl with gcc and the non-default ABI.
The GNU make build system could benefit from a similar test, without
which it does not support MSVC-built Perl. For now, just add a comment.
Most users taking the special step of building Perl with MSVC probably
build PostgreSQL with MSVC.
Discussion: https://postgr.es/m/20171130041441.GA3161526@rfd.leadboat.com
M config/perl.m4
M src/tools/msvc/Mkvcbuild.pm
Fix mistake in comment
commit : 99aa36df374231c1d86c9b899740890b54574cb9
author : Peter Eisentraut <peter_e@gmx.net>
date : Fri, 8 Dec 2017 11:16:23 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Fri, 8 Dec 2017 11:16:23 -0500
Reported-by: Masahiko Sawada <sawada.mshk@gmail.com>
M src/backend/access/transam/xlog.c
doc: Add advice about systemd RemoveIPC
commit : 6a1459f67cd46a244f76d93a116be11bf7c92071
author : Peter Eisentraut <peter_e@gmx.net>
date : Wed, 15 Feb 2017 10:44:07 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Wed, 15 Feb 2017 10:44:07 -0500
Reviewed-by: Magnus Hagander <magnus@hagander.net>
M doc/src/sgml/runtime.sgml
Mark assorted variables PGDLLIMPORT.
commit : e6c7ff9e381bf2b9a0c5170c8ddd309dafa1783b
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 5 Dec 2017 09:24:12 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 5 Dec 2017 09:24:12 -0500
This makes life easier for extension authors who wish to support
Windows.
Brian Cloutier, slightly amended by me.
Discussion: http://postgr.es/m/CAJCy68fscdNhmzFPS4kyO00CADkvXvEa-28H-OtENk-pa2OTWw@mail.gmail.com
M src/include/access/twophase.h
M src/include/commands/extension.h
M src/include/miscadmin.h
M src/include/pgtime.h
M src/include/postmaster/postmaster.h
M src/include/storage/fd.h
M src/include/storage/proc.h
M src/include/tcop/dest.h
M src/include/tcop/tcopprot.h
M src/include/utils/guc.h
M src/include/utils/snapmgr.h
Clean up assorted messiness around AllocateDir() usage.
commit : 5eefe7452ed06ab6e52590459324ad2ee1ef587f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 4 Dec 2017 17:02:52 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 4 Dec 2017 17:02:52 -0500
This patch fixes a couple of low-probability bugs that could lead to
reporting an irrelevant errno value (and hence possibly a wrong SQLSTATE)
concerning directory-open or file-open failures. It also fixes places
where we took shortcuts in reporting such errors, either by using elog
instead of ereport or by using ereport but forgetting to specify an
errcode. And it eliminates a lot of just plain redundant error-handling
code.
In service of all this, export fd.c's formerly-static function
ReadDirExtended, so that external callers can make use of the coding
pattern
dir = AllocateDir(path);
while ((de = ReadDirExtended(dir, path, LOG)) != NULL)
if they'd like to treat directory-open failures as mere LOG conditions
rather than errors. Also fix FreeDir to be a no-op if we reach it
with dir == NULL, as such a coding pattern would cause.
Then, remove code at many call sites that was throwing an error or log
message for AllocateDir failure, as ReadDir or ReadDirExtended can handle
that job just fine. Aside from being a net code savings, this gets rid of
a lot of not-quite-up-to-snuff reports, as mentioned above. (In some
places these changes result in replacing a custom error message such as
"could not open tablespace directory" with more generic wording "could not
open directory", but it was agreed that the custom wording buys little as
long as we report the directory name.) In some other call sites where we
can't just remove code, change the error reports to be fully
project-style-compliant.
Also reorder code in restoreTwoPhaseData that was acquiring a lock
between AllocateDir and ReadDir; in the unlikely but surely not
impossible case that LWLockAcquire changes errno, AllocateDir failures
would be misreported. There is no great value in opening the directory
before acquiring TwoPhaseStateLock, so just do it in the other order.
Also fix CheckXLogRemoved to guarantee that it preserves errno,
as quite a number of call sites are implicitly assuming. (Again,
it's unlikely but I think not impossible that errno could change
during a SpinLockAcquire. If so, this function was broken for its
own purposes as well as breaking callers.)
And change a few places that were using not-per-project-style messages,
such as "could not read directory" when "could not open directory" is
more correct.
Back-patch the exporting of ReadDirExtended, in case we have occasion
to back-patch some fix that makes use of it; it's not needed right now
but surely making it global is pretty harmless. Also back-patch the
restoreTwoPhaseData and CheckXLogRemoved fixes. The rest of this is
essentially cosmetic and need not get back-patched.
Michael Paquier, with a bit of additional work by me
Discussion: https://postgr.es/m/CAB7nPqRpOCxjiirHmebEFhXVTK7V5Jvw4bz82p7Oimtsm3TyZA@mail.gmail.com
M src/backend/access/transam/xlog.c
M src/backend/storage/file/fd.c
M src/include/storage/fd.h
Fix non-GNU makefiles for AIX make.
commit : 93acb892d956651d96a7d229fde479687e98c809
author : Noah Misch <noah@leadboat.com>
date : Thu, 30 Nov 2017 00:57:22 -0800
committer: Noah Misch <noah@leadboat.com>
date : Thu, 30 Nov 2017 00:57:22 -0800
Invoking the Makefile without an explicit target was building every
possible target instead of just the "all" target. Back-patch to 9.3
(all supported versions).
M Makefile
M src/test/regress/Makefile
Fix typo in comment
commit : caa6e12b5deb3ece8828507b2b4d4e1218d42ed7
author : Magnus Hagander <magnus@hagander.net>
date : Mon, 27 Nov 2017 09:30:42 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Mon, 27 Nov 2017 09:30:42 +0100
Andreas Karlsson
M src/tools/msvc/config_default.pl
Make has_sequence_privilege support WITH GRANT OPTION
commit : 69e5b1e9ccd77dae2c8f2f1c684d8cb4826d99e9
author : Joe Conway <mail@joeconway.com>
date : Sun, 26 Nov 2017 09:50:53 -0800
committer: Joe Conway <mail@joeconway.com>
date : Sun, 26 Nov 2017 09:50:53 -0800
The various has_*_privilege() functions all support an optional
WITH GRANT OPTION added to the supported privilege types to test
whether the privilege is held with grant option. That is, all except
has_sequence_privilege() variations. Fix that.
Back-patch to all supported branches.
Discussion: https://postgr.es/m/005147f6-8280-42e9-5a03-dd2c1e4397ef@joeconway.com
M src/backend/utils/adt/acl.c
Update MSVC build process for new timezone data.
commit : a2826ff8b167f7f23ee60ee11f04ec9a5d2aac82
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 25 Nov 2017 18:15:23 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 25 Nov 2017 18:15:23 -0500
Missed this dependency in commits 7cce222c9 et al.
M src/tools/msvc/Install.pm
Replace raw timezone source data with IANA's new compact format.
commit : d46f691581e52cfe2d670a8784e814e37ee0b10d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 25 Nov 2017 15:30:11 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 25 Nov 2017 15:30:11 -0500
Traditionally IANA has distributed their timezone data in pure source
form, replete with extensive historical comments. As of release 2017c,
they've added a compact single-file format that omits comments and
abbreviates command keywords. This form is way shorter than the pure
source, even before considering its allegedly better compressibility.
Hence, let's distribute the data in that form rather than pure source.
I'm pushing this now, rather than at the next timezone database update,
so that it's easy to confirm that this data file produces compiled zic
output that's identical to what we were getting before.
Discussion: https://postgr.es/m/1915.1511210334@sss.pgh.pa.us
M src/timezone/Makefile
M src/timezone/README
D src/timezone/data/africa
D src/timezone/data/antarctica
D src/timezone/data/asia
D src/timezone/data/australasia
D src/timezone/data/backward
D src/timezone/data/backzone
D src/timezone/data/etcetera
D src/timezone/data/europe
D src/timezone/data/factory
D src/timezone/data/northamerica
D src/timezone/data/pacificnew
D src/timezone/data/southamerica
D src/timezone/data/systemv
A src/timezone/data/tzdata.zi
Avoid formally-undefined use of memcpy() in hstoreUniquePairs().
commit : 6e9ac0a2e2a62449f0c1a89563f80b7bb71c6121
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 25 Nov 2017 14:42:10 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 25 Nov 2017 14:42:10 -0500
hstoreUniquePairs() often called memcpy with equal source and destination
pointers. Although this is almost surely harmless in practice, it's
undefined according to the letter of the C standard. Some versions of
valgrind will complain about it, and some versions of libc as well
(cf. commit ad520ec4a). Tweak the code to avoid doing that.
Noted by Tomas Vondra. Back-patch to all supported versions because
of the hazard of libc assertions.
Discussion: https://postgr.es/m/bf84d940-90d4-de91-19dd-612e011007f4@fuzzy.cz
M contrib/hstore/hstore_io.c
Repair failure with SubPlans in multi-row VALUES lists.
commit : d538f65684a50214240b26f39d1062e9800139dd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 25 Nov 2017 14:15:48 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 25 Nov 2017 14:15:48 -0500
When nodeValuesscan.c was written, it was impossible to have a SubPlan in
VALUES --- any sub-SELECT there would have to be uncorrelated and thereby
would produce an InitPlan instead. We therefore took a shortcut in the
logic that throws away a ValuesScan's per-row expression evaluation data
structures. This was broken by the introduction of LATERAL however; a
sub-SELECT containing a lateral reference produces a correlated SubPlan.
The cleanest fix for this would be to give up the optimization of
discarding the expression eval state. But that still seems pretty
unappetizing for long VALUES lists. It seems to work to just prevent
the subexpressions from hooking into the ValuesScan node's subPlan
list, so let's do that and see how well it works. (If this breaks,
due to additional connections between the subexpressions and the outer
query structures, we might consider compromises like throwing away data
only for VALUES rows not containing SubPlans.)
Per bug #14924 from Christian Duta. Back-patch to 9.3 where LATERAL
was introduced.
Discussion: https://postgr.es/m/20171124120836.1463.5310@wrigleys.postgresql.org
M src/backend/executor/nodeValuesscan.c
M src/test/regress/expected/subselect.out
M src/test/regress/sql/subselect.sql
Support linking with MinGW-built Perl.
commit : 83e6b143440220e43b9437e3ce7e37b611852996
author : Noah Misch <noah@leadboat.com>
date : Thu, 23 Nov 2017 20:22:04 -0800
committer: Noah Misch <noah@leadboat.com>
date : Thu, 23 Nov 2017 20:22:04 -0800
This is necessary for ActivePerl 5.18 onwards and for Strawberry Perl.
It is not sufficient for 32-bit builds with newer Visual Studio; these
fail with error LINK2026. Back-patch to 9.3 (all supported versions).
Reported by Victor Wagner.
Discussion: https://postgr.es/m/20160326154321.7754ab8f@wagner.wagner.home
M config/perl.m4
M configure
M src/pl/plperl/plperl.h
M src/tools/msvc/Mkvcbuild.pm
Provide for forward compatibility with future minor protocol versions.
commit : aa3a78c3ddaf380355dc5264acd2eb8e128ee422
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 21 Nov 2017 13:56:24 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 21 Nov 2017 13:56:24 -0500
Previously, any attempt to request a 3.x protocol version other than
3.0 would lead to a hard connection failure, which made the minor
protocol version really no different from the major protocol version
and precluded gentle protocol version breaks. Instead, when the
client requests a 3.x protocol version where x is greater than 0, send
the new NegotiateProtocolVersion message to convey that we support
only 3.0. This makes it possible to introduce new minor protocol
versions without requiring a connection retry when the server is
older.
In addition, if the startup packet includes name/value pairs where
the name starts with "_pq_.", assume that those are protocol options,
not GUCs. Include those we don't support (i.e. all of them, at
present) in the NegotiateProtocolVersion message so that the client
knows they were not understood. This makes it possible for the
client to request previously-unsupported features without bumping
the protocol version at all; the client can tell from the server's
response whether the option was understood.
It will take some time before servers that support these new
facilities become common in the wild; to speed things up and make
things easier for a future 3.1 protocol version, back-patch to all
supported releases.
Robert Haas and Badrul Chowdhury
Discussion: http://postgr.es/m/BN6PR21MB0772FFA0CBD298B76017744CD1730@BN6PR21MB0772.namprd21.prod.outlook.com
Discussion: http://postgr.es/m/30788.1498672033@sss.pgh.pa.us
M doc/src/sgml/protocol.sgml
M src/backend/postmaster/postmaster.c
Use out-of-line M68K spinlock code for OpenBSD as well as NetBSD.
commit : 1056dd0e94f349882deaca072e80b58529ed8c3c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 20 Nov 2017 18:05:03 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 20 Nov 2017 18:05:03 -0500
David Carlier (from a patch being carried by OpenBSD packagers)
Discussion: https://postgr.es/m/CA+XhMqzwFSGVU7MEnfhCecc8YdP98tigXzzpd0AAdwaGwaVXEA@mail.gmail.com
M src/backend/storage/lmgr/s_lock.c
Add support for Motorola 88K to s_lock.h.
commit : 0245c75f4f241901c62067c32ccd8afc1d3db3b2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 20 Nov 2017 17:57:46 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 20 Nov 2017 17:57:46 -0500
Apparently there are still people out there who care about this old
architecture. They probably care about dusty versions of Postgres
too, so back-patch to all supported branches.
David Carlier (from a patch being carried by OpenBSD packagers)
Discussion: https://postgr.es/m/CA+XhMqzwFSGVU7MEnfhCecc8YdP98tigXzzpd0AAdwaGwaVXEA@mail.gmail.com
M src/include/storage/s_lock.h
Provide modern examples of how to auto-start Postgres on macOS.
commit : 77b76fea94cdffe0e936292103780a45d7e0ddb3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Nov 2017 12:46:52 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 Nov 2017 12:46:52 -0500
The scripts in contrib/start-scripts/osx don't work at all on macOS
10.10 (Yosemite) or later, because they depend on SystemStarter which
Apple deprecated long ago and removed in 10.10. Add a new subdirectory
contrib/start-scripts/macos with scripts that use the newer launchd
infrastructure.
Since this problem is independent of which Postgres version you're using,
back-patch to all supported branches.
Discussion: https://postgr.es/m/31338.1510763554@sss.pgh.pa.us
A contrib/start-scripts/macos/README
A contrib/start-scripts/macos/org.postgresql.postgres.plist
A contrib/start-scripts/macos/postgres-wrapper.sh
M contrib/start-scripts/osx/README
MSVC: Rebuild spiexceptions.h when out of date.
commit : ca853a244559b339b3a9da321844b852367e8140
author : Noah Misch <noah@leadboat.com>
date : Sun, 12 Nov 2017 18:43:32 -0800
committer: Noah Misch <noah@leadboat.com>
date : Sun, 12 Nov 2017 18:43:32 -0800
Also, add a warning to catch future instances of naming a nonexistent
file as a prerequisite. Back-patch to 9.3 (all supported versions).
M src/tools/msvc/Solution.pm
Install Windows crash dump handler before all else.
commit : 1c065901e3408c3db43593e55aa32da32302dd87
author : Noah Misch <noah@leadboat.com>
date : Sun, 12 Nov 2017 14:31:00 -0800
committer: Noah Misch <noah@leadboat.com>
date : Sun, 12 Nov 2017 14:31:00 -0800
Apart from calling write_stderr() on failure, the handler depends on no
PostgreSQL facilities. We have experienced crashes before reaching the
former call site. Given such an early crash, this change cannot hurt
and may produce a helpful dump. Absent an early crash, this change has
no effect. Back-patch to 9.3 (all supported versions).
Takayuki Tsunakawa
Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F80CD13@G01JPEXMBYT05
M src/backend/main/main.c
Don't call pgwin32_message_to_UTF16() without CurrentMemoryContext.
commit : 30e99efe82c71c0320983dee5a9789e9f3f8a8e3
author : Noah Misch <noah@leadboat.com>
date : Sun, 12 Nov 2017 13:03:15 -0800
committer: Noah Misch <noah@leadboat.com>
date : Sun, 12 Nov 2017 13:03:15 -0800
PostgreSQL running as a Windows service crashed upon calling
write_stderr() before MemoryContextInit(). This fix completes work
started in 5735efee15540765315aa8c1a230575e756037f7. Messages this
early contain only ASCII bytes; if we removed the CurrentMemoryContext
requirement, the ensuing conversions would have no effect. Back-patch
to 9.3 (all supported versions).
Takayuki Tsunakawa, reviewed by Michael Paquier.
Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1F80CC73@G01JPEXMBYT05
M src/backend/utils/error/elog.c
Add post-2010 ecpg tests to checktcp.
commit : 4cd5d8a9eb7be2906602a97d39c2bd4fb9e8153f
author : Noah Misch <noah@leadboat.com>
date : Sat, 11 Nov 2017 14:39:06 -0800
committer: Noah Misch <noah@leadboat.com>
date : Sat, 11 Nov 2017 14:39:06 -0800
This suite had been a proper superset of the regular ecpg test suite,
but the three newest tests didn't reach it. To make this less likely to
recur, delete the extra schedule file and pass the TCP-specific test on
the command line. Back-patch to 9.3 (all supported versions).
M src/interfaces/ecpg/test/Makefile
D src/interfaces/ecpg/test/ecpg_schedule_tcp
Make connect/test1 independent of localhost IPv6.
commit : ad21f3481d14ae156c8287a4e23bdd570a50b1b0
author : Noah Misch <noah@leadboat.com>
date : Sat, 11 Nov 2017 14:33:02 -0800
committer: Noah Misch <noah@leadboat.com>
date : Sat, 11 Nov 2017 14:33:02 -0800
Since commit 868898739a8da9ab74c105b8349b7b5c711f265a, it has assumed
"localhost" resolves to both ::1 and 127.0.0.1. We gain nothing from
that assumption, and it does not hold in a default installation of Red
Hat Enterprise Linux 5. Back-patch to 9.3 (all supported versions).
M src/interfaces/ecpg/test/connect/test1.pgc
M src/interfaces/ecpg/test/expected/connect-test1.c
M src/interfaces/ecpg/test/expected/connect-test1.stderr
Fix previous commit's test, for non-UTF8 databases with non-XML builds.
commit : f5260d5ad43ba04c63f0b44f532af9ae58703076
author : Noah Misch <noah@leadboat.com>
date : Sat, 11 Nov 2017 13:07:46 -0800
committer: Noah Misch <noah@leadboat.com>
date : Sat, 11 Nov 2017 13:07:46 -0800
To ensure stable output, catch one more configuration-specific error.
Back-patch to 9.3, like the commit that added the test.
M src/test/regress/expected/xml.out
M src/test/regress/expected/xml_1.out
M src/test/regress/expected/xml_2.out
M src/test/regress/sql/xml.sql
Ignore XML declaration in xpath_internal(), for UTF8 databases.
commit : d8406b9de910bf77d74ac644817b42fb4cf2ad03
author : Noah Misch <noah@leadboat.com>
date : Sat, 11 Nov 2017 11:10:53 -0800
committer: Noah Misch <noah@leadboat.com>
date : Sat, 11 Nov 2017 11:10:53 -0800
When a value contained an XML declaration naming some other encoding,
this function interpreted UTF8 bytes as the named encoding, yielding
mojibake. xml_parse() already has similar logic. This would be
necessary but not sufficient for non-UTF8 databases, so preserve
behavior there until the xpath facility can support such databases
comprehensively. Back-patch to 9.3 (all supported versions).
Pavel Stehule and Noah Misch
Discussion: https://postgr.es/m/CAFj8pRC-dM=tT=QkGi+Achkm+gwPmjyOayGuUfXVumCxkDgYWg@mail.gmail.com
M src/backend/utils/adt/xml.c
M src/test/regress/expected/xml.out
M src/test/regress/expected/xml_1.out
M src/test/regress/expected/xml_2.out
M src/test/regress/sql/xml.sql
Fix some null pointer dereferences in LDAP auth code
commit : 62906461c0d2765e0b7f8222b080670ddf1825b0
author : Peter Eisentraut <peter_e@gmx.net>
date : Fri, 10 Nov 2017 14:21:32 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Fri, 10 Nov 2017 14:21:32 -0500
An LDAP URL without a host name such as "ldap://" or without a base DN
such as "ldap://localhost" would cause a crash when reading pg_hba.conf.
If no binddn is configured, an error message might end up trying to print a
null pointer, which could crash on some platforms.
Author: Thomas Munro <thomas.munro@enterprisedb.com>
Reviewed-by: Michael Paquier <michael.paquier@gmail.com>
M src/backend/libpq/auth.c
M src/backend/libpq/hba.c
Add -wnet to SP invocations
commit : 89afa724c6384b8f64f115f7b866c8625e158f22
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 9 Nov 2017 17:06:32 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 9 Nov 2017 17:06:32 -0500
This causes a warning when accidentally backpatching an XML-style
empty-element tag like <xref linkend="abc"/>.
M doc/src/sgml/Makefile
Revert "Allow --with-bonjour to work with non-macOS implementations of Bonjour."
commit : 89df643c3b3350de1b0e0d5cddd2f439972ca00f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 9 Nov 2017 11:00:36 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 9 Nov 2017 11:00:36 -0500
Upon further review, our Bonjour code doesn't actually work with the
Avahi not-too-compatible compatibility library. While you can get it
to work on non-macOS platforms if you link to Apple's own mDNSResponder
code, there don't seem to be many people who care about that. Leaving in
the AC_SEARCH_LIBS call seems more likely to encourage people to build
broken configurations than to do anything very useful.
Hence, remove the AC_SEARCH_LIBS call and put in a warning comment instead.
Discussion: https://postgr.es/m/2D8331C5-D64F-44C1-8717-63EDC6EAF7EB@brightforge.com
M configure
M configure.in
Allow --with-bonjour to work with non-macOS implementations of Bonjour.
commit : 9042e927eafb2b3f1d5d0c02d9640d357a5a12a7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 8 Nov 2017 17:47:14 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 8 Nov 2017 17:47:14 -0500
On macOS the relevant functions require no special library, but elsewhere
we need to pull in libdns_sd.
Back-patch to supported branches. No docs change since the docs do not
suggest that this is a Mac-only feature.
Luke Lonergan
Discussion: https://postgr.es/m/2D8331C5-D64F-44C1-8717-63EDC6EAF7EB@brightforge.com
M configure
M configure.in
Fix two violations of the ResourceOwnerEnlarge/Remember protocol.
commit : 13492fcf9bb1a25034db3e5ec200a999b1efc371
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 8 Nov 2017 16:50:13 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 8 Nov 2017 16:50:13 -0500
The point of having separate ResourceOwnerEnlargeFoo and
ResourceOwnerRememberFoo functions is so that resource allocation
can happen in between. Doing it in some other order is just wrong.
OpenTemporaryFile() did open(), enlarge, remember, which would leak the
open file if the enlarge step ran out of memory. Because fd.c has its own
layer of resource-remembering, the consequences look like they'd be limited
to an intratransaction FD leak, but it's still not good.
IncrBufferRefCount() did enlarge, remember, incr-refcount, which would blow
up if the incr-refcount step ever failed. It was safe enough when written,
but since the introduction of PrivateRefCountHash, I think the assumption
that no error could happen there is pretty shaky.
The odds of real problems from either bug are probably small, but still,
back-patch to supported branches.
Thomas Munro and Tom Lane, per a comment from Andres Freund
M src/backend/storage/buffer/bufmgr.c
M src/backend/storage/file/fd.c
Fix unportable usage of <ctype.h> functions.
commit : 806fc522688c45ea40c57fb843775fcea40e0bd4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 7 Nov 2017 13:49:36 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 7 Nov 2017 13:49:36 -0500
isdigit(), isspace(), etc are likely to give surprising results if passed a
signed char. We should always cast the argument to unsigned char to avoid
that. Error in commit 63d6b97fd, found by buildfarm member gaur.
Back-patch to 9.3, like that commit.
M src/interfaces/ecpg/ecpglib/data.c