Stamp 9.6.2.
commit : 6a18e4bc2d13d077c52cf90a4c6ec68343808ba7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Feb 2017 16:45:25 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Feb 2017 16:45:25 -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
Release notes for 9.6.2, 9.5.6, 9.4.11, 9.3.16, 9.2.20.
commit : a822971173e66cde920a0a20352b823cd873db0f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Feb 2017 15:30:16 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Feb 2017 15:30:16 -0500
M doc/src/sgml/release-9.2.sgml
M doc/src/sgml/release-9.3.sgml
M doc/src/sgml/release-9.4.sgml
M doc/src/sgml/release-9.5.sgml
M doc/src/sgml/release-9.6.sgml
Avoid returning stale attribute bitmaps in RelationGetIndexAttrBitmap().
commit : 7fcddbdd031f1644952c26eebd3e0aa7007e9d37
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Feb 2017 13:19:51 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 6 Feb 2017 13:19:51 -0500
The problem with the original coding here is that we might receive (and
clear) a relcache invalidation signal for the target relation down inside
one of the index_open calls we're doing. Since the target is open, we
would not drop the relcache entry, just reset its rd_indexvalid and
rd_indexlist fields. But RelationGetIndexAttrBitmap() kept going, and
would eventually cache and return potentially-obsolete attribute bitmaps.
The case where this matters is where the inval signal was from a CREATE
INDEX CONCURRENTLY telling us about a new index on a formerly-unindexed
column. (In all other cases, the lock we hold on the target rel should
prevent any concurrent change in index state.) Even just returning the
stale attribute bitmap is not such a problem, because it shouldn't matter
during the transaction in which we receive the signal. What hurts is
caching the stale data, because it can survive into later transactions,
breaking CREATE INDEX CONCURRENTLY's expectation that later transactions
will not create new broken HOT chains. The upshot is that there's a window
for building corrupted indexes during CREATE INDEX CONCURRENTLY.
This patch fixes the problem by rechecking that the set of index OIDs
is still the same at the end of RelationGetIndexAttrBitmap() as it was
at the start. If not, we loop back and try again. That's a little
more than is strictly necessary to fix the bug --- in principle, we
could return the stale data but not cache it --- but it seems like a
bad idea on general principles for relcache to return data it knows
is stale.
There might be more hazards of the same ilk, or there might be a better
way to fix this one, but this patch definitely improves matters and seems
unlikely to make anything worse. So let's push it into today's releases
even as we continue to study the problem.
Pavan Deolasee and myself
Discussion: https://postgr.es/m/CABOikdM2MUq9cyZJi1KyLmmkCereyGp5JQ4fuwKoyKEde_mzkQ@mail.gmail.com
M src/backend/utils/cache/relcache.c
Translation updates
commit : 5853b9493510e12d9b82bf8fe3f6a1248027be2b
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 6 Feb 2017 12:42:47 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 6 Feb 2017 12:42:47 -0500
Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 7a27441a7432f1a9d12f2b1b517497c73ee5d20d
M src/backend/nls.mk
M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/fr.po
A src/backend/po/ko.po
M src/backend/po/ru.po
M src/bin/initdb/po/fr.po
M src/bin/initdb/po/ru.po
M src/bin/pg_basebackup/po/fr.po
M src/bin/pg_config/po/fr.po
M src/bin/pg_controldata/po/fr.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_ctl/po/fr.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_dump/po/fr.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_resetxlog/po/fr.po
M src/bin/pg_resetxlog/po/ru.po
M src/bin/pg_rewind/po/fr.po
M src/bin/pg_rewind/po/pt_BR.po
M src/bin/pg_rewind/po/ru.po
M src/bin/psql/po/fr.po
M src/bin/psql/po/pt_BR.po
M src/bin/psql/po/ru.po
M src/bin/scripts/po/fr.po
M src/bin/scripts/po/ru.po
M src/interfaces/ecpg/ecpglib/po/fr.po
M src/interfaces/ecpg/preproc/po/fr.po
M src/interfaces/ecpg/preproc/po/pt_BR.po
M src/interfaces/ecpg/preproc/po/ru.po
M src/interfaces/libpq/po/fr.po
M src/interfaces/libpq/po/ru.po
M src/pl/plperl/po/fr.po
M src/pl/plpgsql/src/po/fr.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpython/po/de.po
M src/pl/plpython/po/fr.po
M src/pl/plpython/po/ru.po
M src/pl/tcl/po/fr.po
M src/pl/tcl/po/ru.po
Add missing newline to error messages
commit : d48f273b3144b72e4f6ab1e704e64cc48b4026fa
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 6 Feb 2017 09:47:39 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 6 Feb 2017 09:47:39 -0500
Also improve the message style a bit while we're here.
M src/bin/pg_dump/pg_dump.c
Fix typo also in expected output.
commit : 50baad4433112c60c7c901d0939c009322b6cedb
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 6 Feb 2017 12:04:04 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 6 Feb 2017 12:04:04 +0200
Commit 181bdb90ba fixed the typo in the .sql file, but forgot to update the
expected output.
M contrib/sepgsql/expected/label.out
Fix typos in comments.
commit : 90e85992199469ca1191aadd3ab0222a158576be
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 6 Feb 2017 11:33:58 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Mon, 6 Feb 2017 11:33:58 +0200
Backpatch to all supported versions, where applicable, to make backpatching
of future fixes go more smoothly.
Josh Soref
Discussion: https://www.postgresql.org/message-id/CACZqfqCf+5qRztLPgmmosr-B0Ye4srWzzw_mo4c_8_B_mtjmJQ@mail.gmail.com
M configure
M configure.in
M contrib/bloom/blvacuum.c
M contrib/cube/expected/cube.out
M contrib/cube/expected/cube_1.out
M contrib/cube/expected/cube_2.out
M contrib/cube/expected/cube_3.out
M contrib/cube/sql/cube.sql
M contrib/earthdistance/earthdistance–1.1.sql
M contrib/isn/ISSN.h
M contrib/isn/isn.c
M contrib/ltree/expected/ltree.out
M contrib/ltree/ltxtquery_io.c
M contrib/ltree/sql/ltree.sql
M contrib/pg_standby/pg_standby.c
M contrib/pg_stat_statements/pg_stat_statements.c
M contrib/pg_trgm/trgm_op.c
M contrib/pgcrypto/mbuf.c
M contrib/pgcrypto/pgp-mpi-internal.c
M contrib/pgcrypto/pgp-mpi-openssl.c
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
M contrib/seg/seg.c
M contrib/sepgsql/selinux.c
M contrib/sepgsql/sql/label.sql
M contrib/spi/refint.c
M contrib/start-scripts/osx/PostgreSQL
M contrib/tsearch2/tsearch2–1.0.sql
M contrib/xml2/xpath.c
M src/Makefile.shlib
M src/backend/access/gist/README
M src/backend/access/heap/rewriteheap.c
M src/backend/access/transam/commit_ts.c
M src/backend/access/transam/xact.c
M src/backend/catalog/objectaddress.c
M src/backend/commands/amcmds.c
M src/backend/commands/dbcommands.c
M src/backend/commands/explain.c
M src/backend/commands/functioncmds.c
M src/backend/commands/indexcmds.c
M src/backend/commands/tablecmds.c
M src/backend/executor/execParallel.c
M src/backend/executor/nodeWindowAgg.c
M src/backend/libpq/hba.c
M src/backend/optimizer/geqo/geqo_erx.c
M src/backend/optimizer/path/joinpath.c
M src/backend/optimizer/plan/planmain.c
M src/backend/optimizer/util/joininfo.c
M src/backend/optimizer/util/restrictinfo.c
M src/backend/parser/gram.y
M src/backend/postmaster/bgwriter.c
M src/backend/postmaster/postmaster.c
M src/backend/replication/logical/origin.c
M src/backend/replication/logical/reorderbuffer.c
M src/backend/replication/logical/snapbuild.c
M src/backend/storage/ipc/latch.c
M src/backend/storage/ipc/shm_mq.c
M src/backend/storage/lmgr/lock.c
M src/backend/storage/lmgr/lwlock.c
M src/backend/storage/lmgr/predicate.c
M src/backend/tsearch/spell.c
M src/backend/tsearch/ts_parse.c
M src/backend/tsearch/wparser_def.c
M src/backend/utils/adt/formatting.c
M src/backend/utils/adt/rangetypes_selfuncs.c
M src/backend/utils/adt/ruleutils.c
M src/backend/utils/adt/tsrank.c
M src/backend/utils/adt/windowfuncs.c
M src/backend/utils/cache/relcache.c
M src/backend/utils/fmgr/funcapi.c
M src/backend/utils/init/postinit.c
M src/backend/utils/misc/Makefile
M src/backend/utils/time/tqual.c
M src/bin/pg_dump/pg_backup_custom.c
M src/bin/psql/common.c
M src/bin/psql/describe.c
M src/include/access/visibilitymap.h
M src/include/access/xact.h
M src/include/c.h
M src/include/storage/s_lock.h
M src/include/tsearch/dicts/spell.h
M src/interfaces/ecpg/ecpglib/execute.c
M src/interfaces/ecpg/pgtypeslib/datetime.c
M src/interfaces/ecpg/pgtypeslib/numeric.c
M src/interfaces/ecpg/preproc/ecpg.header
M src/interfaces/ecpg/preproc/ecpg.trailer
M src/interfaces/ecpg/preproc/parse.pl
M src/interfaces/libpq/fe-auth.c
M src/interfaces/libpq/libpq-int.h
M src/interfaces/libpq/win32.c
M src/pl/plperl/ppport.h
M src/pl/plpython/plpy_elog.c
M src/pl/plpython/plpy_plpymodule.c
M src/pl/plpython/plpy_typeio.h
M src/test/isolation/specs/receipt-report.spec
M src/test/isolation/specs/two-ids.spec
M src/test/regress/expected/alter_table.out
M src/test/regress/expected/indirect_toast.out
M src/test/regress/expected/init_privs.out
M src/test/regress/expected/insert_conflict.out
M src/test/regress/expected/join.out
M src/test/regress/expected/matview.out
M src/test/regress/expected/plpgsql.out
M src/test/regress/expected/replica_identity.out
M src/test/regress/expected/rolenames.out
M src/test/regress/expected/rules.out
M src/test/regress/expected/tsdicts.out
M src/test/regress/sql/alter_table.sql
M src/test/regress/sql/indirect_toast.sql
M src/test/regress/sql/init_privs.sql
M src/test/regress/sql/insert_conflict.sql
M src/test/regress/sql/join.sql
M src/test/regress/sql/matview.sql
M src/test/regress/sql/plpgsql.sql
M src/test/regress/sql/replica_identity.sql
M src/test/regress/sql/rolenames.sql
M src/test/regress/sql/rules.sql
M src/test/regress/sql/tsdicts.sql
M src/test/ssl/ServerSetup.pm
Fix placement of initPlans when forcibly materializing a subplan.
commit : b971a98cea988e03054077db613fc893564f7bf7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 2 Feb 2017 19:11:27 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 2 Feb 2017 19:11:27 -0500
If we forcibly place a Material node atop a finished subplan, we need
to move any initPlans attached to the subplan up to the Material node,
in order to keep SS_finalize_plan() happy. I'd figured this out in
commit 7b67a0a49 for the case of materializing a cursor plan, but out of
an abundance of caution, I put the initPlan movement hack at the call
site for that case, rather than inside materialize_finished_plan().
That was the wrong thing, because it turns out to also be necessary for
the only other caller of materialize_finished_plan(), ie subselect.c.
We lacked any test cases that exposed the mistake, but bug#14524 from
Wei Congrui shows that it's possible to get an initPlan reference into
the top tlist in that case too, and then SS_finalize_plan() complains.
Hence, move the hack into materialize_finished_plan().
In HEAD, also relocate some recently-added tests in subselect.sql, which
I'd unthinkingly dropped into the middle of a sequence of related tests.
Report: https://postgr.es/m/20170202060020.1400.89021@wrigleys.postgresql.org
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/plan/planner.c
M src/test/regress/expected/subselect.out
M src/test/regress/sql/subselect.sql
Add KOI8-U map files to Makefile.
commit : 3aab31bbc74b4898d62b83868be5f47215cd36f7
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 2 Feb 2017 14:12:35 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 2 Feb 2017 14:12:35 +0200
These were left out by mistake back when support for KOI8-U encoding was
added.
Extracted from Kyotaro Horiguchi's larger patch.
M src/backend/utils/mb/Unicode/Makefile
Don't count background workers against a user's connection limit.
commit : 13752743bf7010f7cbf07bdf2a0087c3960121c5
author : Andrew Dunstan <andrew@dunslane.net>
date : Wed, 1 Feb 2017 17:52:35 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Wed, 1 Feb 2017 17:52:35 -0500
Doing so doesn't seem to be within the purpose of the per user
connection limits, and has particularly unfortunate effects in
conjunction with parallel queries.
Backpatch to 9.6 where parallel queries were introduced.
David Rowley, reviewed by Robert Haas and Albe Laurenz.
M doc/src/sgml/ref/create_database.sgml
M doc/src/sgml/ref/create_role.sgml
M src/backend/access/transam/twophase.c
M src/backend/storage/ipc/procarray.c
M src/backend/storage/lmgr/proc.c
M src/backend/utils/init/postinit.c
M src/include/storage/proc.h
M src/include/storage/procarray.h
pg_dump: Fix handling of ALTER DEFAULT PRIVILEGES
commit : eb5e9d90df7536d0cf5c0d669d874f91b7be36d6
author : Stephen Frost <sfrost@snowman.net>
date : Tue, 31 Jan 2017 16:24:14 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Tue, 31 Jan 2017 16:24:14 -0500
In commit 23f34fa, we changed how ACLs were handled to use the new
pg_init_privs catalog and to dump out the ACL commands as REVOKE+GRANT
combinations instead of trying to REVOKE all rights always and then
GRANT back just the ones which were in place.
Unfortunately, the DEFAULT PRIVILEGES system didn't quite get the
correct treatment with this change and ended up (incorrectly) only
including positive GRANTs instead of both the REVOKEs and GRANTs
necessary to preserve the correct privileges.
There are only a couple cases where such REVOKEs are possible because,
generally speaking, there's few rights which exist on objects by
default to be revoked.
Examples of REVOKEs which weren't being correctly preserved are when
privileges are REVOKE'd from the creator/owner, like so:
ALTER DEFAULT PRIVILEGES
FOR ROLE myrole
REVOKE SELECT ON TABLES FROM myrole;
or when other default privileges are being revoked, such as EXECUTE
rights granted to public for functions:
ALTER DEFAULT PRIVILEGES
FOR ROLE myrole
REVOKE EXECUTE ON FUNCTIONS FROM PUBLIC;
Fix this by correctly working out what the correct REVOKE statements are
(if any) and dump them out, just as we do for everything else.
Noticed while developing additional regression tests for pg_dump, which
will be landing shortly.
Back-patch to 9.6 where the bug was introduced.
M src/bin/pg_dump/dumputils.c
M src/bin/pg_dump/dumputils.h
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h
test_pg_dump: perltidy cleanup
commit : 3e9c36165377b07ffb182c366e295ac48ea5d5ba
author : Stephen Frost <sfrost@snowman.net>
date : Tue, 31 Jan 2017 11:17:40 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Tue, 31 Jan 2017 11:17:40 -0500
As pointed out by Alvaro, we actually use perltidy on the perl scripts
in the source tree, so go back to the results of a perltidy run for the
test_pg_dump TAP script.
To make it look slightly less tragic, I changed most of the independent
arguments into long-form single arguments (eg: -f file.sql changed to be
--file=file.sql) to avoid having them confusingly split across lines due
to perltidy.
Back-patch to 9.6, as the last patch was.
M src/test/modules/test_pg_dump/t/001_base.pl
Update time zone data files to tzdata release 2016j.
commit : 6da67b684a605ed320b39fe974d631fe5682e8bc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 30 Jan 2017 11:40:22 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 30 Jan 2017 11:40:22 -0500
DST law changes in northern Cyprus (new zone Asia/Famagusta), Russia (new
zone Europe/Saratov), Tonga, Antarctica/Casey. Historical corrections for
Asia/Aqtau, Asia/Atyrau, Asia/Gaza, Asia/Hebron, Italy, Malta. Replace
invented zone abbreviation "TOT" for Tonga with numeric UTC offset; but
as in the past, we'll keep accepting "TOT" for input.
M src/timezone/data/africa
M src/timezone/data/antarctica
M src/timezone/data/asia
M src/timezone/data/australasia
M src/timezone/data/europe
M src/timezone/known_abbrevs.txt
M src/timezone/tznames/Default
M src/timezone/tznames/Pacific.txt
Handle ALTER EXTENSION ADD/DROP with pg_init_privs
commit : 20064c0ec201fd2302757c1fdb2279e9dc9a4030
author : Stephen Frost <sfrost@snowman.net>
date : Sun, 29 Jan 2017 23:05:09 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Sun, 29 Jan 2017 23:05:09 -0500
In commit 6c268df, pg_init_privs was added to track the initial
privileges of catalog objects and extensions. Unfortunately, that
commit didn't include understanding of ALTER EXTENSION ADD/DROP, which
allows the objects associated with an extension to be changed after the
initial CREATE EXTENSION script has been run.
The result of this meant that ACLs for objects added through
ALTER EXTENSION ADD were not recorded into pg_init_privs and we would
end up including those ACLs in pg_dump when we shouldn't have.
This commit corrects that by making sure to have pg_init_privs updated
when ALTER EXTENSION ADD/DROP is run, recording the permissions as they
are at ALTER EXTENSION ADD time, and removing any if/when ALTER
EXTENSION DROP is called.
This issue was pointed out by Moshe Jacobson as commentary on bug #14456
(which was actually a bug about versions prior to 9.6 not handling
custom ACLs on extensions correctly, an issue now addressed with
pg_init_privs in 9.6).
Back-patch to 9.6 where pg_init_privs was introduced.
M src/backend/catalog/aclchk.c
M src/backend/commands/extension.c
M src/include/utils/acl.h
M src/test/modules/test_pg_dump/expected/test_pg_dump.out
M src/test/modules/test_pg_dump/sql/test_pg_dump.sql
M src/test/modules/test_pg_dump/t/001_base.pl
test_pg_dump TAP test whitespace cleanup
commit : 73cd4896f41052bdaf779fa1b63aca5f10c56a62
author : Stephen Frost <sfrost@snowman.net>
date : Sun, 29 Jan 2017 23:05:09 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Sun, 29 Jan 2017 23:05:09 -0500
The formatting of the perl hashes used in the TAP tests for test_pg_dump
was rather horribly inconsistent and made it more difficult than it
really should have been to add new tests or adjust what tests are for
what runs, etc.
Reformat to clean that all up.
Whitespace-only changes.
M src/test/modules/test_pg_dump/t/001_base.pl
Orthography fixes for new castNode() macro.
commit : 60c1d8ffae74d0142f068a21f889b5890ff61142
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 27 Jan 2017 08:33:58 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 27 Jan 2017 08:33:58 -0500
Clean up hastily-composed comment. Normalize whitespace.
Erik Rijkers and myself
M src/include/nodes/nodes.h
Check interrupts during hot standby waits
commit : 40b7800da24de920cb9478a22605fa4715dbc30d
author : Simon Riggs <simon@2ndQuadrant.com>
date : Fri, 27 Jan 2017 12:13:20 +0000
committer: Simon Riggs <simon@2ndQuadrant.com>
date : Fri, 27 Jan 2017 12:13:20 +0000
M src/backend/storage/ipc/standby.c
Add castNode(type, ptr) for safe casting between NodeTag based types.
commit : 574b091e583597f4ba7905cfd84f7669dfa2a41c
author : Andres Freund <andres@anarazel.de>
date : Thu, 26 Jan 2017 16:47:03 -0800
committer: Andres Freund <andres@anarazel.de>
date : Thu, 26 Jan 2017 16:47:03 -0800
The new function allows to cast from one NodeTag based type to
another, while asserting that the conversion is valid. This replaces
the common pattern of doing a cast and a Assert(IsA(ptr, type))
close-by.
As this seems likely to be used pervasively, we decided to backpatch
this change the addition of this macro. Otherwise backpatched fixes
are more likely not to work on back-branches.
On branches before 9.6, where we do not yet rely on inline functions
being available, the type assertion is only performed if PG_USE_INLINE
support is detected. The cast obviously is performed regardless.
For the benefit of verifying the macro compiles in the back-branches,
this commit contains a single use of the new macro. On master, a
somewhat larger conversion will be committed separately.
Author: Peter Eisentraut and Andres Freund
Reviewed-By: Tom Lane
Discussion: https://postgr.es/m/c5d387d9-3440-f5e0-f9d4-71d53b9fbe52@2ndquadrant.com
Backpatch: 9.2-
M src/backend/tcop/postgres.c
M src/include/nodes/nodes.h
Remove test for COMMENT ON DATABASE
commit : 56b42a3341671fbbb69bbc5247f9062df32a3c06
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 26 Jan 2017 17:45:22 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 26 Jan 2017 17:45:22 -0300
Our current DDL only allows a database name to be specified in COMMENT
ON DATABASE, which Andrew Dunstan reports to make this test fail on the
buildfarm. Remove the line until we gain a DDL command that allows the
current database to be operated on without having the specify it by
name.
Backpatch to 9.5, where these tests appeared.
Discussion: https://postgr.es/m/e6084b89-07a7-7e57-51ee-d7b8fc9ec864@2ndQuadrant.com
M src/test/modules/test_ddl_deparse/expected/comment_on.out
M src/test/modules/test_ddl_deparse/sql/comment_on.sql
Reset hot standby xmin after restart
commit : 95d1b41450e93a9af146bc836f7f3b1ad13a1f2a
author : Simon Riggs <simon@2ndQuadrant.com>
date : Thu, 26 Jan 2017 20:06:44 +0000
committer: Simon Riggs <simon@2ndQuadrant.com>
date : Thu, 26 Jan 2017 20:06:44 +0000
Hot_standby_feedback could be reset by reload and worked correctly, but if
the server was restarted rather than reloaded the xmin was not reset.
Force reset always if hot_standby_feedback is enabled at startup.
Ants Aasma, Craig Ringer
Reported-by: Ants Aasma
M src/backend/replication/walreceiver.c
Ensure that a tsquery like '!foo' matches empty tsvectors.
commit : 2dfc12647138deadabfc32123692021b7dd9a94f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 26 Jan 2017 12:17:47 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 26 Jan 2017 12:17:47 -0500
!foo means "the tsvector does not contain foo", and therefore it should
match an empty tsvector. ts_match_vq() overenthusiastically supposed
that an empty tsvector could never match any query, so it forcibly
returned FALSE, the wrong answer. Remove the premature optimization.
Our behavior on this point was inconsistent, because while seqscans and
GIST index searches both failed to match empty tsvectors, GIN index
searches would find them, since GIN scans don't rely on ts_match_vq().
That makes this certainly a bug, not a debatable definition disagreement,
so back-patch to all supported branches.
Report and diagnosis by Tom Dunstan (bug #14515); added test cases by me.
Discussion: https://postgr.es/m/20170126025524.1434.97828@wrigleys.postgresql.org
M src/backend/utils/adt/tsvector_op.c
M src/test/regress/expected/tsearch.out
M src/test/regress/expected/tstypes.out
M src/test/regress/sql/tsearch.sql
M src/test/regress/sql/tstypes.sql
Fix comments in StrategyNotifyBgWriter().
commit : e4e5ea64c002308654990e7ecc2b1d3d5fec01e3
author : Tatsuo Ishii <ishii@postgresql.org>
date : Tue, 24 Jan 2017 09:39:11 +0900
committer: Tatsuo Ishii <ishii@postgresql.org>
date : Tue, 24 Jan 2017 09:39:11 +0900
The interface for the function was changed in
d72731a70450b5e7084991b9caa15cb58a2820df but the comments of the
function was not updated.
Patch by Yugo Nagata.
M src/backend/storage/buffer/freelist.c
doc: Update URL for Microsoft download site
commit : 012691a04eb9b6e2e49722f57d440a31286f1715
author : Peter Eisentraut <peter_e@gmx.net>
date : Tue, 17 Jan 2017 12:00:00 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Tue, 17 Jan 2017 12:00:00 -0500
M doc/src/sgml/install-windows.sgml
Avoid useless respawining the autovacuum launcher at high speed.
commit : 746ba76f1e15e2a7de1bda1eab9b1b8d84875ea5
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 20 Jan 2017 15:55:45 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 20 Jan 2017 15:55:45 -0500
When (1) autovacuum = off and (2) there's at least one database with
an XID age greater than autovacuum_freeze_max_age and (3) all tables
in that database that need vacuuming are already being processed by a
worker and (4) the autovacuum launcher is started, a kind of infinite
loop occurs. The launcher starts a worker and immediately exits. The
worker, finding no worker to do, immediately starts the launcher,
supposedly so that the next database can be processed. But because
datfrozenxid for that database hasn't been advanced yet, the new
worker gets put right back into the same database as the old one,
where it once again starts the launcher and exits. High-speed ping
pong ensues.
There are several possible ways to break the cycle; this seems like
the safest one.
Amit Khandekar (code) and Robert Haas (comments), reviewed by
Álvaro Herrera.
Discussion: http://postgr.es/m/CAJ3gD9eWejf72HKquKSzax0r+epS=nAbQKNnykkMA0E8c+rMDg@mail.gmail.com
M src/backend/postmaster/autovacuum.c
Dump sequence data based on the TableDataInfo flag
commit : fd081cabf7c3ce514d28e8de1a9b5c8717ea1130
author : Stephen Frost <sfrost@snowman.net>
date : Thu, 19 Jan 2017 12:06:27 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Thu, 19 Jan 2017 12:06:27 -0500
When considering a sequence's Data entry in dumpSequenceData, we were
actually looking at the sequence definition's dump flag to decide if we
should dump the data or not. That's generally fine, except for when the
sequence data entry was created by processExtensionTables() because it's
a config sequence. In that case, the sequence itself won't be marked as
dumping data because it's part of an extension, leading to the need for
processExtensionTables() to create the sequence data entry.
This leads to extension config sequence data not being included in the
dump when it should be. Fix this by looking at the sequence data's dump
flag instead, just as dumpTableData() was doing for tables (which is why
config tables were correctly being handled), and add a regression test
to make sure we don't break it moving forward.
All of this is a bit round-about since we can now represent which
components of a given dump item should be dumped out through the dump
flag. A future improvement might be to change checkExtensionMembership()
to check for config sequences/tables and set the dump flag based on that
directly, possibly removing the need for processExtensionTables().
Bug found by Daniele Varrazzo.
Discussion: https://postgr.es/m/CA+mi_8ZmxQM7+nZ7pJ8uyfxc9V3o=UAG14dVqvftdmvw8OJ3gQ@mail.gmail.com
Patch by Michael Paquier, with some tweaking of the regression tests by
me.
Back-patch to 9.6 where the bug was introduced.
M src/bin/pg_dump/pg_dump.c
M src/test/modules/test_pg_dump/t/001_base.pl
M src/test/modules/test_pg_dump/test_pg_dump–1.0.sql
Reset the proper GUC in create_index test.
commit : 692a70427a0ac4fd5aea869d3f03c1a23cc42035
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 18 Jan 2017 16:33:18 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 18 Jan 2017 16:33:18 -0500
Thinko in commit a4523c5aa. It doesn't really affect anything at
present, but it would be a problem if any tests added later in this
file ought to get index-only-scan plans. Back-patch, like the previous
commit, just to avoid surprises in case we add such a test and then
back-patch it.
Nikita Glukhov
Discussion: https://postgr.es/m/8b70135d-ad38-bdd8-ac92-71e2b3c273cf@postgrespro.ru
M src/test/regress/expected/create_index.out
M src/test/regress/sql/create_index.sql
Change some test macros to return true booleans
commit : fce4609d5e5b7fc01e921f9fa3a6e75356284db6
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 18 Jan 2017 18:06:13 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 18 Jan 2017 18:06:13 -0300
These macros work fine when they are used directly in an "if" test or
similar, but as soon as the return values are assigned to boolean
variables (or passed as boolean arguments to some function), they become
bugs, hopefully caught by compiler warnings. To avoid future problems,
fix the definitions so that they return actual booleans.
To further minimize the risk that somebody uses them in back-patched
fixes that only work correctly in branches starting from the current
master and not in old ones, back-patch the change to supported branches
as appropriate.
See also commit af4472bcb88ab36b9abbe7fd5858e570a65a2d1a, and the long
discussion (and larger patch) in the thread mentioned in its commit
message.
Discussion: https://postgr.es/m/18672.1483022414@sss.pgh.pa.us
M src/include/access/htup_details.h
Disable transforms that replaced AT TIME ZONE with RelabelType.
commit : b21e665f2df7ba6611d2fa6f845e4803deaf14c3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 18 Jan 2017 15:21:52 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 18 Jan 2017 15:21:52 -0500
These resulted in wrong answers if the relabeled argument could be matched
to an index column, as shown in bug #14504 from Evgeniy Kozlov. We might
be able to resurrect these optimizations by adjusting the planner's
treatment of RelabelType, or by adjusting btree's rules for selecting
comparison functions, but either solution will take careful analysis
and does not sound like a fit candidate for backpatching.
I left the catalog infrastructure in place and just reduced the transform
functions to always-return-NULL. This would be necessary anyway in the
back branches, and it doesn't seem important to be more invasive in HEAD.
Bug introduced by commit b8a18ad48. Back-patch to 9.5 where that came in.
Report: https://postgr.es/m/20170118144828.1432.52823@wrigleys.postgresql.org
Discussion: https://postgr.es/m/18771.1484759439@sss.pgh.pa.us
M src/backend/utils/adt/timestamp.c
M src/test/regress/expected/timestamptz.out
M src/test/regress/sql/timestamptz.sql
Fix an assertion failure related to an exclusive backup.
commit : 60a8b63d24321f5162dfcaf1502936c7ed00b63e
author : Fujii Masao <fujii@postgresql.org>
date : Tue, 17 Jan 2017 17:29:15 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Tue, 17 Jan 2017 17:29:15 +0900
Previously multiple sessions could execute pg_start_backup() and
pg_stop_backup() to start and stop an exclusive backup at the same time.
This could trigger the assertion failure of
"FailedAssertion("!(XLogCtl->Insert.exclusiveBackup)".
This happend because, even while pg_start_backup() was starting
an exclusive backup, other session could run pg_stop_backup()
concurrently and mark the backup as not-in-progress unconditionally.
This patch introduces ExclusiveBackupState indicating the state of
an exclusive backup. This state is used to ensure that there is only
one session running pg_start_backup() or pg_stop_backup() at
the same time, to avoid the assertion failure.
Back-patch to all supported versions.
Author: Michael Paquier
Reviewed-By: Kyotaro Horiguchi and me
Reported-By: Andreas Seltenreich
Discussion: <87mvktojme.fsf@credativ.de>
M src/backend/access/transam/xlog.c
Throw suitable error for COPY TO STDOUT/FROM STDIN in a SQL function.
commit : 8a70d8ae7501141d283e56b31e10c66697c986d5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 14 Jan 2017 13:27:47 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 14 Jan 2017 13:27:47 -0500
A client copy can't work inside a function because the FE/BE wire protocol
doesn't support nesting of a COPY operation within query results. (Maybe
it could, but the protocol spec doesn't suggest that clients should support
this, and libpq for one certainly doesn't.)
In most PLs, this prohibition is enforced by spi.c, but SQL functions don't
use SPI. A comparison of _SPI_execute_plan() and init_execution_state()
shows that rejecting client COPY is the only discrepancy in what they
allow, so there's no other similar bugs.
This is an astonishingly ancient oversight, so back-patch to all supported
branches.
Report: https://postgr.es/m/BY2PR05MB2309EABA3DEFA0143F50F0D593780@BY2PR05MB2309.namprd05.prod.outlook.com
M src/backend/executor/functions.c
pg_upgrade: Fix for changed pg_ctl default stop mode
commit : f7acc0397c60ed13137d7392e4210eb0f9d5877e
author : Peter Eisentraut <peter_e@gmx.net>
date : Fri, 13 Jan 2017 12:00:00 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Fri, 13 Jan 2017 12:00:00 -0500
In 9.5, the default pg_ctl stop mode was changed from "smart" to "fast".
pg_upgrade still thought the default mode was "smart" and only specified
the mode when "fast" was asked for. This results in using "fast" all
the time. It's not clear what the effect in practice is, but fix it
nonetheless to restore the previous behavior.
M src/bin/pg_upgrade/server.c
Fix cardinality estimates for parallel joins.
commit : 2d443ae1b0121e15265864d2b2143509fa70e8e4
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 13 Jan 2017 13:29:31 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 13 Jan 2017 13:29:31 -0500
For a partial path, the cardinality estimate needs to reflect the
number of rows we think each worker will see, rather than the total
number of rows; otherwise, costing will go wrong. The previous coding
got this completely wrong for parallel joins.
Unfortunately, this change may destabilize plans for users of 9.6 who
have enabled parallel query, but since 9.6 is still fairly new I'm
hoping expectations won't be too settled yet. Also, this is really a
brown-paper-bag bug, so leaving it unfixed for the entire lifetime of
9.6 seems unwise.
Related reports (whose import I initially failed to recognize) by
Tomas Vondra and Tom Lane.
Discussion: http://postgr.es/m/CA+TgmoaDxZ5z5Kw_oCQoymNxNoVaTCXzPaODcOuao=CzK8dMZw@mail.gmail.com
M src/backend/optimizer/path/costsize.c
Fix mistake in comment
commit : d2d7163d470908c6325af73a7aea9eebeb52341d
author : Peter Eisentraut <peter_e@gmx.net>
date : Thu, 12 Jan 2017 12:00:00 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Thu, 12 Jan 2017 12:00:00 -0500
The node->restart() function doesn't take a mode argument.
M src/test/perl/PostgresNode.pm
pg_restore: Don't allow non-positive number of jobs
commit : 4b5f399177ecd1ae0e94606fc7c251931c5987b6
author : Stephen Frost <sfrost@snowman.net>
date : Wed, 11 Jan 2017 15:45:53 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Wed, 11 Jan 2017 15:45:53 -0500
pg_restore will currently accept invalid values for the number of
parallel jobs to run (eg: -1), unlike pg_dump which does check that the
value provided is reasonable.
Worse, '-1' is actually a valid, independent, parameter (as an alias for
--single-transaction), leading to potentially completely unexpected
results from a command line such as:
-> pg_restore -j -1
Where a user would get neither parallel jobs nor a single-transaction.
Add in validity checking of the parallel jobs option, as we already have
in pg_dump, before we try to open up the archive. Also move the check
that we haven't been asked to run more parallel jobs than possible on
Windows to the same place, so we do all the option validity checking
before opening the archive.
Back-patch all the way, though for 9.2 we're adding the Windows-specific
check against MAXIMUM_WAIT_OBJECTS as that check wasn't back-patched
originally.
Discussion: https://www.postgresql.org/message-id/20170110044815.GC18360%40tamriel.snowman.net
M src/bin/pg_dump/pg_restore.c
pg_xlogdump: document --path behavior
commit : 1c15f843485bf36e279686b6ed0b659232b975bb
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 10 Jan 2017 22:38:13 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 10 Jan 2017 22:38:13 -0500
The previous --path documentation and --help output were wrong in both
its meaning and the defaults.
Reviewed-by: Michael Paquier
Backpatch-through: 9.6
M doc/src/sgml/ref/pg_xlogdump.sgml
M src/bin/pg_xlogdump/pg_xlogdump.c
pg_dump: Strict names with no matching schema
commit : 22a85b3fbe85a9f1c92de90192de001b7394b4fe
author : Stephen Frost <sfrost@snowman.net>
date : Tue, 10 Jan 2017 11:34:55 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Tue, 10 Jan 2017 11:34:55 -0500
When using pg_dump --strict-names and a schema pattern which doesn't
match any schemas (eg: --schema='nonexistant*'), we were incorrectly
throwing an error claiming no tables were found when, really, there
were no schemas found:
-> pg_dump --strict-names --schema='nonexistant*'
pg_dump: no matching tables were found for pattern "nonexistant*"
Fix that by changing the error message to say 'schemas' instead, since
that is what we are actually complaining about.
Noticed while testing pg_dump error cases.
Back-patch to 9.6 where --strict-names and this error message were
introduced.
M src/bin/pg_dump/pg_dump.c
Fix invalid-parallel-jobs error message
commit : 96f2344f381df94fcb9b84bffc58bbc540edd842
author : Stephen Frost <sfrost@snowman.net>
date : Mon, 9 Jan 2017 23:09:33 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Mon, 9 Jan 2017 23:09:33 -0500
Including the program name twice is not helpful:
-> pg_dump -j -1
pg_dump: pg_dump: invalid number of parallel jobs
Correct by removing the progname from the exit_horribly() call used when
validating the number of parallel jobs.
Noticed while testing various pg_dump error cases.
Back-patch to 9.3 where parallel pg_dump was added.
M src/bin/pg_dump/pg_dump.c
Fix ALTER TABLE / SET TYPE for irregular inheritance
commit : 4e563a1f6532decf7949324d313f264a4ed38622
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 9 Jan 2017 19:26:58 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 9 Jan 2017 19:26:58 -0300
If inherited tables don't have exactly the same schema, the USING clause
in an ALTER TABLE / SET DATA TYPE misbehaves when applied to the
children tables since commit 9550e8348b79. Starting with that commit,
the attribute numbers in the USING expression are fixed during parse
analysis. This can lead to bogus errors being reported during
execution, such as:
ERROR: attribute 2 has wrong type
DETAIL: Table has type smallint, but query expects integer.
Since it wouldn't do to revert to the original coding, we now apply a
transformation to map the attribute numbers to the correct ones for each
child.
Reported by Justin Pryzby
Analysis by Tom Lane; patch by me.
Discussion: https://postgr.es/m/20170102225618.GA10071@telsasoft.com
M src/backend/access/common/tupconvert.c
M src/backend/commands/tablecmds.c
M src/include/access/tupconvert.h
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
BRIN revmap pages are not standard pages ...
commit : 4482c6a23f03ba3186d44a41ca77b80a4dee0b38
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 9 Jan 2017 18:19:29 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 9 Jan 2017 18:19:29 -0300
... and therefore we ought not to tell XLogRegisterBuffer the opposite,
when writing XLog for a brin update that moves the index tuple to a
different page. Otherwise, xlog insertion would try to "compress the
hole" when producing a full-page image for it; but since we don't update
pd_lower/upper, the hole covers the whole page. On WAL replay, the
revmap page becomes empty and so the entire portion of the index is
useless and needs to be recomputed.
This is low-probability: a BRIN update only moves an index tuple to a
different page when the summary tuple is larger than the existing one,
which doesn't happen with fixed-width datatypes. Also, the revmap
page must be first after a checkpoint.
Report and patch: Kuntal Ghosh
Bug is alleged to have detected by a WAL-consistency-checking tool.
Discussion: https://postgr.es/m/CAGz5QCJ=00UQjScSEFbV=0qO5ShTZB9WWz_Fm7+Wd83zPs9Geg@mail.gmail.com
I posted a test case demonstrating the problem, but I'm refraining from
adding it to the test suite; if the WAL consistency tool makes it in,
that will be a better way to catch this from regressing. (We should
definitely have someting that causes not-same-page updates, though.)
M src/backend/access/brin/brin_pageops.c
Protect against NULL-dereference in pg_dump
commit : 8b1bf3161b360003182997b4e258b8fac78c3bdf
author : Stephen Frost <sfrost@snowman.net>
date : Fri, 6 Jan 2017 15:27:50 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Fri, 6 Jan 2017 15:27:50 -0500
findTableByOid() is allowed to return NULL and we should therefore be
checking for that case. getOwnedSeqs() and dumpSequence() shouldn't
ever actually see this happen, but given odd circumstances it might and
commit f9e439b1 probably shouldn't have removed that check.
Pointed out by Coverity. Initial patch from Michael Paquier.
Back-patch to 9.6, where that commit had removed the check.
M src/bin/pg_dump/pg_dump.c
Invalidate cached plans on FDW option changes.
commit : 4103a2f200d6050b6c71e5c3c79c70ea98020307
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 6 Jan 2017 14:12:52 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 6 Jan 2017 14:12:52 -0500
This fixes problems where a plan must change but fails to do so,
as seen in a bug report from Rajkumar Raghuwanshi.
For ALTER FOREIGN TABLE OPTIONS, do this through the standard method of
forcing a relcache flush on the table. For ALTER FOREIGN DATA WRAPPER
and ALTER SERVER, just flush the whole plan cache on any change in
pg_foreign_data_wrapper or pg_foreign_server. That matches the way
we handle some other low-probability cases such as opclass changes, and
it's unclear that the case arises often enough to be worth working harder.
Besides, that gives a patch that is simple enough to back-patch with
confidence.
Back-patch to 9.3. In principle we could apply the code change to 9.2 as
well, but (a) we lack postgres_fdw to test it with, (b) it's doubtful that
anyone is doing anything exciting enough with FDWs that far back to need
this desperately, and (c) the patch doesn't apply cleanly.
Patch originally by Amit Langote, reviewed by Etsuro Fujita and Ashutosh
Bapat, who each contributed substantial changes as well.
Discussion: https://postgr.es/m/CAKcux6m5cA6rRPTKkqVdJ-R=KKDfe35Q_ZuUqxDSV_4hwga=og@mail.gmail.com
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
M src/backend/commands/tablecmds.c
M src/backend/utils/cache/plancache.c
Fix possible leak of semaphore count.
commit : 603299167f4aaa857c0156b492ad51143e33fc2f
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 5 Jan 2017 13:12:16 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 5 Jan 2017 13:12:16 -0500
Commit 4aec49899e5782247e134f94ce1c6ee926f88e1c reorganized the order
of operations here so that we no longer increment the number of "extra
waits" before locking the semaphore, but it did not change the
starting value of extraWaits from 0 to -1 to compensate. In the worst
case, this could leak a semaphore count, but that seems to be unlikely
in practice.
Discussion: http://postgr.es/m/CAA4eK1JyVqXiMba+-a589Rk0pyHsyKkGxeumVKjU6Y74hdrVLQ@mail.gmail.com
Amit Kapila, per an off-list report by Dilip Kumar. Reviewed by me.
M src/backend/storage/ipc/procarray.c
Fix handling of empty arrays in array_fill().
commit : 5b4f8f4c6d618063f7dde0a710a4076fb444620a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 5 Jan 2017 11:33:51 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 5 Jan 2017 11:33:51 -0500
array_fill(..., array[0]) produced an empty array, which is probably
what users expect, but it was a one-dimensional zero-length array
which is not our standard representation of empty arrays. Also, for
no very good reason, it rejected empty input arrays; that case should
be allowed and produce an empty output array.
In passing, remove the restriction that the input array(s) have lower
bound 1. That seems rather pointless, and it would have needed extra
complexity to make the check deal with empty input arrays.
Per bug #14487 from Andrew Gierth. It's been broken all along, so
back-patch to all supported branches.
Discussion: https://postgr.es/m/20170105152156.10135.64195@wrigleys.postgresql.org
M src/backend/utils/adt/arrayfuncs.c
M src/test/regress/expected/arrays.out
M src/test/regress/sql/arrays.sql
Handle OID column inheritance correctly in ALTER TABLE ... INHERIT.
commit : f64554b99a00ed0fe4097811dfa94265581c27ae
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 4 Jan 2017 18:00:11 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 4 Jan 2017 18:00:11 -0500
Inheritance operations must treat the OID column, if any, much like
regular user columns. But MergeAttributesIntoExisting() neglected to
do that, leading to weird results after a table with OIDs is associated
to a parent with OIDs via ALTER TABLE ... INHERIT.
Report and patch by Amit Langote, reviewed by Ashutosh Bapat, some
adjustments by me. It's been broken all along, so back-patch to
all supported branches.
Discussion: https://postgr.es/m/cb13cfe7-a48c-5720-c383-bb843ab28298@lab.ntt.co.jp
M src/backend/commands/tablecmds.c
M src/test/regress/expected/inherit.out
M src/test/regress/sql/inherit.sql
Prefer int-wide pg_atomic_flag over char-wide when using gcc intrinsics.
commit : 6e5de703b6c791d355936a61abb52b3b1fc6e184
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 4 Jan 2017 13:36:44 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 4 Jan 2017 13:36:44 -0500
configure can only probe the existence of gcc intrinsics, not how well
they're implemented, and unfortunately the answer is sometimes "badly".
In particular we've found that multiple compilers fail to implement
char-width __sync_lock_test_and_set() correctly on PPC; and even a correct
implementation would necessarily be pretty inefficient, since that hardware
has only a word-wide primitive to work with.
Given the knowledge we've accumulated in s_lock.h, it appears that it's
best to rely on int-width TAS operations on most non-Intel architectures.
Hence, pick int not char when both are nominally available to us in
generic-gcc.h (note that that code is not used for x86[_64]).
Back-patch to fix regression test failures on FreeBSD/PPC. Ordinarily
back-patching a change like this would be verboten because of ABI breakage.
But since pg_atomic_flag is not yet used in any Postgres data structure,
there's no ABI to break. It seems safer to back-patch to avoid possible
gotchas, if someday we do back-patch something that uses pg_atomic_flag.
Discussion: https://postgr.es/m/25414.1483076673@sss.pgh.pa.us
M src/include/port/atomics/generic-gcc.h
Update copyright for 2017
commit : 344ae600ac036675d52afca9e8b363628d78d36d
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Jan 2017 12:37:53 -0500
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 3 Jan 2017 12:37:53 -0500
Backpatch-through: certain files through 9.2
M COPYRIGHT
M doc/src/sgml/legal.sgml
Remove bogus notice that older clients might not work with MD5 passwords.
commit : 7546c135dc300b33fe02ffde892a32f92b3a5438
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 3 Jan 2017 14:09:01 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 3 Jan 2017 14:09:01 +0200
That was written when we still had "crypt" authentication, and it was
referring to the fact that an older client might support "crypt"
authentication but not "md5". But we haven't supported "crypt" for years.
(As soon as we add a new authentication mechanism that doesn't work with
MD5 hashes, we'll need a similar notice again. But this text as it's worded
now is just wrong.)
Backpatch to all supported versions.
Discussion: https://www.postgresql.org/message-id/9a7263eb-0980-2072-4424-440bb2513dc7@iki.fi
M doc/src/sgml/ref/create_role.sgml
Silence compiler warnings
commit : 5099e8ee23641abc8437d98555b63158e75a8a55
author : Joe Conway <mail@joeconway.com>
date : Mon, 2 Jan 2017 14:42:28 -0800
committer: Joe Conway <mail@joeconway.com>
date : Mon, 2 Jan 2017 14:42:28 -0800
Rearrange a bit of code to ensure that 'mode' in LWLockRelease is
obviously always set, which seems a bit cleaner and avoids a compiler
warning (thanks to Robert for the suggestion!).
Back-patch back to 9.5 where the warning is first seen.
Author: Stephen Frost
Discussion: https://postgr.es/m/20161129152102.GR13284%40tamriel.snowman.net
M src/backend/storage/lmgr/lwlock.c
Silence compiler warnings
commit : 7911e78f6cc5a51f4d41589542140eee00b3f10d
author : Joe Conway <mail@joeconway.com>
date : Mon, 2 Jan 2017 14:11:50 -0800
committer: Joe Conway <mail@joeconway.com>
date : Mon, 2 Jan 2017 14:11:50 -0800
In GetCachedPlan(), initialize 'plan' to silence a compiler warning, but
also add an Assert() to make sure we don't ever actually fall through
with 'plan' still being set to NULL, since we are about to dereference
it.
Back-patch back to 9.2.
Author: Stephen Frost
Discussion: https://postgr.es/m/20161129152102.GR13284%40tamriel.snowman.net
M src/backend/utils/cache/plancache.c
Fix incorrect example of to_timestamp() usage.
commit : f7e7d6fcefc4083d929075be5e121114086a6f98
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 29 Dec 2016 18:05:34 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 29 Dec 2016 18:05:34 -0500
Must use HH24 not HH to read a hour value exceeding 12.
This was already fixed in HEAD in commit d3cd36a13, but I didn't think
of backpatching it.
Report: https://postgr.es/m/20161229170043.10139.21416@wrigleys.postgresql.org
M doc/src/sgml/func.sgml
Fix interval_transform so it doesn't throw away non-no-op casts.
commit : 21e24eb9a0829fb40011055e389cbcf50670521d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 27 Dec 2016 15:43:54 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 27 Dec 2016 15:43:54 -0500
interval_transform() contained two separate bugs that caused it to
sometimes mistakenly decide that a cast from interval to restricted
interval is a no-op and throw it away.
First, it was wrong to rely on dt.h's field type macros to have an
ordering consistent with the field's significance; in one case they do
not. This led to mistakenly treating YEAR as less significant than MONTH,
so that a cast from INTERVAL MONTH to INTERVAL YEAR was incorrectly
discarded.
Second, fls(1<<k) produces k+1 not k, so comparing its output directly
to SECOND was wrong. This led to supposing that a cast to INTERVAL
MINUTE was really a cast to INTERVAL SECOND and so could be discarded.
To fix, get rid of the use of fls(), and make a function based on
intervaltypmodout to produce a field ID code adapted to the need here.
Per bug #14479 from Piotr Stefaniak. Back-patch to 9.2 where transform
functions were introduced, because this code was born broken.
Discussion: https://postgr.es/m/20161227172307.10135.7747@wrigleys.postgresql.org
M src/backend/utils/adt/timestamp.c
M src/test/regress/expected/interval.out
M src/test/regress/sql/interval.sql
Explain unaccounted for space in pgstattuple.
commit : e9cf6e685beacdf24f6873d597a5c78ff9beb679
author : Andrew Dunstan <andrew@dunslane.net>
date : Tue, 27 Dec 2016 11:23:46 -0500
committer: Andrew Dunstan <andrew@dunslane.net>
date : Tue, 27 Dec 2016 11:23:46 -0500
In addition to space accounted for by tuple_len, dead_tuple_len and
free_space, the table_len includes page overhead, the item pointers
table and padding bytes.
Backpatch to live branches.
M doc/src/sgml/pgstattuple.sgml
Remove triggerable Assert in hashname().
commit : 462ab6c8b2b8a0cc332d869fe5fbdf30f8d98356
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 26 Dec 2016 14:58:02 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 26 Dec 2016 14:58:02 -0500
hashname() asserted that the key string it is given is shorter than
NAMEDATALEN. That should surely always be true if the input is in fact a
regular value of type "name". However, for reasons of coding convenience,
we allow plain old C strings to be treated as "name" values in many places.
Some SQL functions accept arbitrary "text" inputs, convert them to C
strings, and pass them otherwise-untransformed to syscache lookups for name
columns, allowing an overlength input value to trigger hashname's Assert.
This would be a DOS problem, except that it only happens in assert-enabled
builds which aren't recommended for production. In a production build,
you'll just get a name lookup error, since regardless of the hash value
computed by hashname, the later equality comparison checks can't match.
Likewise, if the catalog lookup is done by seqscan or indexscan searches,
there will just be a lookup error, since the name comparison functions
don't contain any similar length checks, and will see an overlength input
as unequal to any stored entry.
After discussion we concluded that we should simply remove this Assert.
It's inessential to hashname's own functionality, and having such an
assertion in only some paths for name lookup is more of a foot-gun than
a useful check. There may or may not be a case for the affected callers
to do something other than let the name lookup fail, but we'll consider
that separately; in any case we probably don't want to change such
behavior in the back branches.
Per report from Tushar Ahuja. Back-patch to all supported branches.
Report: https://postgr.es/m/7d0809ee-6f25-c9d6-8e74-5b2967830d49@enterprisedb.com
Discussion: https://postgr.es/m/17691.1482523168@sss.pgh.pa.us
M src/backend/access/hash/hashfunc.c
Fix incorrect error reporting for duplicate data in \crosstabview.
commit : 6a8c67f5070161c721f1a8e2189836d3a73d8ef5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 25 Dec 2016 16:04:31 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 25 Dec 2016 16:04:31 -0500
\crosstabview's complaint about multiple entries for the same crosstab
cell quoted the wrong row and/or column values. It would accidentally
appear to work if the data had been in strcmp() order to start with,
which probably explains how we missed noticing this during development.
This could be fixed in more than one way, but the way I chose was to
hang onto both result pointers from bsearch() and use those to get at
the value names.
In passing, avoid casting away const in the bsearch comparison functions.
No bug there, just poor style.
Per bug #14476 from Tomonari Katsumata. Back-patch to 9.6 where
\crosstabview was introduced.
Report: https://postgr.es/m/20161225021519.10139.45460@wrigleys.postgresql.org
M src/bin/psql/crosstabview.c
M src/test/regress/expected/psql_crosstab.out
M src/test/regress/sql/psql_crosstab.sql
pg_dumpall: Include --verbose option in --help output
commit : d51af6570520a457a2177edb6df0471c492c3bc0
author : Stephen Frost <sfrost@snowman.net>
date : Sat, 24 Dec 2016 01:42:07 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Sat, 24 Dec 2016 01:42:07 -0500
The -v/--verbose option was not included in the output from --help for
pg_dumpall even though it's in the pg_dumpall documentation and has
apparently been around since pg_dumpall was reimplemented in C in 2002.
Fix that by adding it.
Pointed out by Daniel Westermann.
Back-patch to all supported branches.
Discussion: https://www.postgresql.org/message-id/2020970042.4589542.1482482101585.JavaMail.zimbra%40dbi-services.com
M src/bin/pg_dump/pg_dumpall.c
Fix tab completion in psql for ALTER DEFAULT PRIVILEGES
commit : dc61580bd9a6ad869478c9e6f7ba76cb6314f864
author : Stephen Frost <sfrost@snowman.net>
date : Fri, 23 Dec 2016 21:01:33 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Fri, 23 Dec 2016 21:01:33 -0500
When providing tab completion for ALTER DEFAULT PRIVILEGES, we are
including the list of roles as possible options for completion after the
GRANT or REVOKE. Further, we accept FOR ROLE/IN SCHEMA at the same time
and in either order, but the tab completion was only working for one or
the other. Lastly, we weren't using the actual list of allowed kinds of
objects for default privileges for completion after the 'GRANT X ON' but
instead were completeing to what 'GRANT X ON' supports, which isn't the
ssame at all.
Address these issues by improving the forward tab-completion for ALTER
DEFAULT PRIVILEGES and then constrain and correct how the tail
completion is done when it is for ALTER DEFAULT PRIVILEGES.
Back-patch the forward/tail tab-completion to 9.6, where we made it easy
to handle such cases.
For 9.5 and earlier, correct the initial tab-completion to at least be
correct as far as it goes and then add a check for GRANT/REVOKE to only
tab-complete when the GRANT/REVOKE is the start of the command, so we
don't try to do tab-completion after we get to the GRANT/REVOKE part of
the ALTER DEFAULT PRIVILEGES command, which is better than providing
incorrect completions.
Initial patch for master and 9.6 by Gilles Darold, though I cleaned it
up and added a few comments. All bugs in the 9.5 and earlier patch are
mine.
Discussion: https://www.postgresql.org/message-id/1614593c-e356-5b27-6dba-66320a9bc68b@dalibo.com
M src/bin/psql/tab-complete.c
Doc: improve index entry for "median".
commit : a377c8d921b2fce660043817d52366fd61bf219b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 23 Dec 2016 12:53:09 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 23 Dec 2016 12:53:09 -0500
We had an index entry for "median" attached to the percentile_cont function
entry, which was pretty useless because a person following the link would
never realize that that function was the one they were being hinted to use.
Instead, make the index entry point at the example in syntax-aggregates,
and add a <seealso> link to "percentile".
Also, since that example explicitly claims to be calculating the median,
make it use percentile_cont not percentile_disc. This makes no difference
in terms of the larger goals of that section, but so far as I can find,
nearly everyone thinks that "median" means the continuous not discrete
calculation.
Per gripe from Steven Winfield. Back-patch to 9.4 where we introduced
percentile_cont.
Discussion: https://postgr.es/m/20161223102056.25614.1166@wrigleys.postgresql.org
M doc/src/sgml/func.sgml
M doc/src/sgml/syntax.sgml
Improve RLS documentation with respect to COPY
commit : 51e9df7a1005fc7748c71cd359431f2a41ea678d
author : Joe Conway <mail@joeconway.com>
date : Thu, 22 Dec 2016 17:57:01 -0800
committer: Joe Conway <mail@joeconway.com>
date : Thu, 22 Dec 2016 17:57:01 -0800
Documentation for pg_restore said COPY TO does not support row security
when in fact it should say COPY FROM. Fix that.
While at it, make it clear that "COPY FROM" does not allow RLS to be
enabled and INSERT should be used instead. Also that SELECT policies
will apply to COPY TO statements.
Back-patch to 9.5 where RLS first appeared.
Author: Joe Conway
Reviewed-By: Dean Rasheed and Robert Haas
Discussion: https://postgr.es/m/5744FA24.3030008%40joeconway.com
M doc/src/sgml/ref/copy.sgml
M doc/src/sgml/ref/pg_dump.sgml
M doc/src/sgml/ref/pg_restore.sgml
Use TSConfigRelationId in AlterTSConfiguration()
commit : f0f2e56ac28c05f930ca76c432d61909c9a12cdb
author : Stephen Frost <sfrost@snowman.net>
date : Thu, 22 Dec 2016 17:08:47 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Thu, 22 Dec 2016 17:08:47 -0500
When we are altering a text search configuration, we are getting the
tuple from pg_ts_config and using its OID, so use TSConfigRelationId
when invoking any post-alter hooks and setting the object address.
Further, in the functions called from AlterTSConfiguration(), we're
saving information about the command via
EventTriggerCollectAlterTSConfig(), so we should be setting
commandCollected to true. Also add a regression test to
test_ddl_deparse for ALTER TEXT SEARCH CONFIGURATION.
Author: Artur Zakirov, a few additional comments by me
Discussion: https://www.postgresql.org/message-id/57a71eba-f2c7-e7fd-6fc0-2126ec0b39bd%40postgrespro.ru
Back-patch the fix for the InvokeObjectPostAlterHook() call to 9.3 where
it was introduced, and the fix for the ObjectAddressSet() call and
setting commandCollected to true to 9.5 where those changes to
ProcessUtilitySlow() were introduced.
M src/backend/commands/tsearchcmds.c
M src/backend/tcop/utility.c
M src/test/modules/test_ddl_deparse/Makefile
A src/test/modules/test_ddl_deparse/expected/alter_ts_config.out
A src/test/modules/test_ddl_deparse/sql/alter_ts_config.sql
Fix CREATE TABLE ... LIKE ... WITH OIDS.
commit : 68330c8b42ade797995fb84f46af7549c041ad1e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 22 Dec 2016 16:23:34 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 22 Dec 2016 16:23:34 -0500
Having a WITH OIDS specification should result in the creation of an OID
column, but commit b943f502b broke that in the case that there were LIKE
tables without OIDS. Commentary in that patch makes it look like this was
intentional, but if so it was based on a faulty reading of what inheritance
does: the parent tables can add an OID column, but they can't subtract one.
AFAICS, the behavior ought to be that you get an OID column if any of the
inherited tables, LIKE tables, or WITH clause ask for one.
Also, revert that patch's unnecessary split of transformCreateStmt's loop
over the tableElts list into two passes. That seems to have been based on
a misunderstanding as well: we already have two-pass processing here,
we don't need three passes.
Per bug #14474 from Jeff Dafoe. Back-patch to 9.6 where the misbehavior
was introduced.
Report: https://postgr.es/m/20161222145304.25620.47445@wrigleys.postgresql.org
M src/backend/parser/parse_utilcmd.c
M src/test/regress/expected/create_table_like.out
M src/test/regress/sql/create_table_like.sql
Fix handling of expanded objects in CoerceToDomain and CASE execution.
commit : 77cd0dc7e05a91be5deaed7af37eb055c1f080ed
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 22 Dec 2016 15:01:27 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 22 Dec 2016 15:01:27 -0500
When the input value to a CoerceToDomain expression node is a read-write
expanded datum, we should pass a read-only pointer to any domain CHECK
expressions and then return the original read-write pointer as the
expression result. Previously we were blindly passing the same pointer to
all the consumers of the value, making it possible for a function in CHECK
to modify or even delete the expanded value. (Since a plpgsql function
will absorb a passed-in read-write expanded array as a local variable
value, it will in fact delete the value on exit.)
A similar hazard of passing the same read-write pointer to multiple
consumers exists in domain_check() and in ExecEvalCase, so fix those too.
The fix requires adding MakeExpandedObjectReadOnly calls at the appropriate
places, which is simple enough except that we need to get the data type's
typlen from somewhere. For the domain cases, solve this by redefining
DomainConstraintRef.tcache as okay for callers to access; there wasn't any
reason for the original convention against that, other than not wanting the
API of typcache.c to be any wider than it had to be. For CASE, there's
no good solution except to add a syscache lookup during executor start.
Per bug #14472 from Marcos Castedo. Back-patch to 9.5 where expanded
values were introduced.
Discussion: https://postgr.es/m/15225.1482431619@sss.pgh.pa.us
M src/backend/executor/execQual.c
M src/backend/utils/adt/domains.c
M src/include/nodes/execnodes.h
M src/include/utils/typcache.h
M src/test/regress/expected/case.out
M src/test/regress/expected/plpgsql.out
M src/test/regress/sql/case.sql
M src/test/regress/sql/plpgsql.sql
Fix broken error check in _hash_doinsert.
commit : 17742a05110ee0015f2861e9a4e4b1158c7e69cf
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 22 Dec 2016 13:54:40 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 22 Dec 2016 13:54:40 -0500
You can't just cast a HashMetaPage to a Page, because the meta page
data is stored after the page header, not at offset 0. Fortunately,
this didn't break anything because it happens to find hashm_bsize
at the offset at which it expects to find pd_pagesize_version, and
the values are close enough to the same that this works out.
Still, it's a bug, so back-patch to all supported versions.
Mithun Cy, revised a bit by me.
M src/backend/access/hash/hashinsert.c
Make dblink try harder to form useful error messages
commit : 51126ccdb1ce720b674405e11bcb5e7b8fa902fb
author : Joe Conway <mail@joeconway.com>
date : Thu, 22 Dec 2016 09:47:55 -0800
committer: Joe Conway <mail@joeconway.com>
date : Thu, 22 Dec 2016 09:47:55 -0800
When libpq encounters a connection-level error, e.g. runs out of memory
while forming a result, there will be no error associated with PGresult,
but a message will be placed into PGconn's error buffer. postgres_fdw
takes care to use the PGconn error message when PGresult does not have
one, but dblink has been negligent in that regard. Modify dblink to mirror
what postgres_fdw has been doing.
Back-patch to all supported branches.
Author: Joe Conway
Reviewed-By: Tom Lane
Discussion: https://postgr.es/m/02fa2d90-2efd-00bc-fefc-c23c00eb671e%40joeconway.com
M contrib/dblink/dblink.c
Protect dblink from invalid options when using postgres_fdw server
commit : 150841fb94f651a8e452d7a452c3225c2dafdf16
author : Joe Conway <mail@joeconway.com>
date : Thu, 22 Dec 2016 09:19:34 -0800
committer: Joe Conway <mail@joeconway.com>
date : Thu, 22 Dec 2016 09:19:34 -0800
When dblink uses a postgres_fdw server name for its connection, it
is possible for the connection to have options that are invalid
with dblink (e.g. "updatable"). The recommended way to avoid this
problem is to use dblink_fdw servers instead. However there are use
cases for using postgres_fdw, and possibly other FDWs, for dblink
connection options, therefore protect against trying to use any
options that do not apply by using is_valid_dblink_option() when
building the connection string from the options.
Back-patch to 9.3. Although 9.2 supports FDWs for connection info,
is_valid_dblink_option() did not yet exist, and neither did
postgres_fdw, at least in the postgres source tree. Given the lack
of previous complaints, fixing that seems too invasive/not worth it.
Author: Corey Huinker
Reviewed-By: Joe Conway
Discussion: https://postgr.es/m/CADkLM%3DfWyXVEyYcqbcRnxcHutkP45UHU9WD7XpdZaMfe7S%3DRwA%40mail.gmail.com
M contrib/dblink/dblink.c
Give a useful error message if uuid-ossp is built without preconfiguration.
commit : 60ad2ff586b1bb37930460f4fbba9e4a1c83ded1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 22 Dec 2016 11:19:04 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 22 Dec 2016 11:19:04 -0500
Before commit b8cc8f947, it was possible to build contrib/uuid-ossp without
having told configure you meant to; you could just cd into that directory
and "make". That no longer works because the code depends on configure to
have done header and library probes, but the ensuing error messages are
not so easy to interpret if you're not an old C hand. We've gotten a
couple of complaints recently from people trying to do this the low-tech
way, so add an explicit #error directing the user to use --with-uuid.
(In principle we might want to do something similar in the other
optionally-built contrib modules; but I don't think any of the others have
ever worked without preconfiguration, so there are no bad habits to break
people of.)
Back-patch to 9.4 where the previous commit came in.
Report: https://postgr.es/m/CAHeEsBf42AWTnk=1qJvFv+mYgRFm07Knsfuc86Ono8nRjf3tvQ@mail.gmail.com
Report: https://postgr.es/m/CAKYdkBrUaZX+F6KpmzoHqMtiUqCtAW_w6Dgvr6F0WTiopuGxow@mail.gmail.com
M contrib/uuid-ossp/uuid-ossp.c
Fix buffer overflow on particularly named files and clarify documentation about output file naming.
commit : fd2a5547c523768b662cd2ea056080ad16c9f23f
author : Michael Meskes <meskes@postgresql.org>
date : Thu, 22 Dec 2016 08:28:13 +0100
committer: Michael Meskes <meskes@postgresql.org>
date : Thu, 22 Dec 2016 08:28:13 +0100
Patch by Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com>
M doc/src/sgml/ref/ecpg-ref.sgml
M src/interfaces/ecpg/preproc/ecpg.c
Improve dblink error message when remote does not provide it
commit : 88673c9d3bc72004367e3317175cb873584405bf
author : Joe Conway <mail@joeconway.com>
date : Wed, 21 Dec 2016 15:48:05 -0800
committer: Joe Conway <mail@joeconway.com>
date : Wed, 21 Dec 2016 15:48:05 -0800
When dblink or postgres_fdw detects an error on the remote side of the
connection, it will try to construct a local error message as best it
can using libpq's PQresultErrorField(). When no primary message is
available, it was bailing out with an unhelpful "unknown error". Make
that message better and more style guide compliant. Per discussion
on hackers.
Backpatch to 9.2 except postgres_fdw which didn't exist before 9.3.
Discussion: https://postgr.es/m/19872.1482338965%40sss.pgh.pa.us
M contrib/dblink/dblink.c
M contrib/postgres_fdw/connection.c
Fix detection of unfinished Unicode surrogate pair at end of string.
commit : 88e1e91da58422c5cf0e6e2d32f2aa15d75b8de9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 21 Dec 2016 17:39:32 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 21 Dec 2016 17:39:32 -0500
The U&'...' and U&"..." syntaxes silently discarded a surrogate pair
start (that is, a code between U+D800 and U+DBFF) if it occurred at
the very end of the string. This seems like an obvious oversight,
since we throw an error for every other invalid combination of surrogate
characters, including the very same situation in E'...' syntax.
This has been wrong since the pair processing was added (in 9.0),
so back-patch to all supported branches.
Discussion: https://postgr.es/m/19113.1482337898@sss.pgh.pa.us
M src/backend/parser/scan.l
Fix strange behavior (and possible crashes) in full text phrase search.
commit : 4e2477b7b8b6c025d273a316852f2dbf62fff5bc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 21 Dec 2016 15:18:25 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 21 Dec 2016 15:18:25 -0500
In an attempt to simplify the tsquery matching engine, the original
phrase search patch invented rewrite rules that would rearrange a
tsquery so that no AND/OR/NOT operator appeared below a PHRASE operator.
But this approach had numerous problems. The rearrangement step was
missed by ts_rewrite (and perhaps other places), allowing tsqueries
to be created that would cause Assert failures or perhaps crashes at
execution, as reported by Andreas Seltenreich. The rewrite rules
effectively defined semantics for operators underneath PHRASE that were
buggy, or at least unintuitive. And because rewriting was done in
tsqueryin() rather than at execution, the rearrangement was user-visible,
which is not very desirable --- for example, it might cause unexpected
matches or failures to match in ts_rewrite.
As a somewhat independent problem, the behavior of nested PHRASE operators
was only sane for left-deep trees; queries like "x <-> (y <-> z)" did not
behave intuitively at all.
To fix, get rid of the rewrite logic altogether, and instead teach the
tsquery execution engine to manage AND/OR/NOT below a PHRASE operator
by explicitly computing the match location(s) and match widths for these
operators.
This requires introducing some additional fields into the publicly visible
ExecPhraseData struct; but since there's no way for third-party code to
pass such a struct to TS_phrase_execute, it shouldn't create an ABI problem
as long as we don't move the offsets of the existing fields.
Another related problem was that index searches supposed that "!x <-> y"
could be lossily approximated as "!x & y", which isn't correct because
the latter will reject, say, "x q y" which the query itself accepts.
This required some tweaking in TS_execute_ternary along with the main
tsquery engine.
Back-patch to 9.6 where phrase operators were introduced. While this
could be argued to change behavior more than we'd like in a stable branch,
we have to do something about the crash hazards and index-vs-seqscan
inconsistency, and it doesn't seem desirable to let the unintuitive
behaviors induced by the rewriting implementation stand as precedent.
Discussion: https://postgr.es/m/28215.1481999808@sss.pgh.pa.us
Discussion: https://postgr.es/m/26706.1482087250@sss.pgh.pa.us
M doc/src/sgml/datatype.sgml
M doc/src/sgml/textsearch.sgml
M src/backend/utils/adt/tsginidx.c
M src/backend/utils/adt/tsgistidx.c
M src/backend/utils/adt/tsquery.c
M src/backend/utils/adt/tsquery_cleanup.c
M src/backend/utils/adt/tsquery_op.c
M src/backend/utils/adt/tsvector_op.c
M src/include/tsearch/ts_utils.h
M src/test/regress/expected/tsdicts.out
M src/test/regress/expected/tsearch.out
M src/test/regress/expected/tstypes.out
M src/test/regress/sql/tsearch.sql
M src/test/regress/sql/tstypes.sql
Improve ALTER TABLE documentation
commit : eaac6c75858b693ef5e8968b509114c30896ba19
author : Stephen Frost <sfrost@snowman.net>
date : Wed, 21 Dec 2016 15:03:37 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Wed, 21 Dec 2016 15:03:37 -0500
The ALTER TABLE documentation wasn't terribly clear when it came to
which commands could be combined together and what it meant when they
were.
In particular, SET TABLESPACE *can* be combined with other commands,
when it's operating against a single table, but not when multiple tables
are being moved with ALL IN TABLESPACE. Further, the actions are
applied together but not really in 'parallel', at least today.
Pointed out by: Amit Langote
Improved wording from Tom.
Back-patch to 9.4, where the ALL IN TABLESPACE option was added.
Discussion: https://www.postgresql.org/message-id/14c535b4-13ef-0590-1b98-76af355a0763%40lab.ntt.co.jp
M doc/src/sgml/ref/alter_table.sgml
Fix dumping of casts and transforms using built-in functions
commit : 542975a147525caa659ac08220b81c32a60f0a5c
author : Stephen Frost <sfrost@snowman.net>
date : Wed, 21 Dec 2016 13:47:13 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Wed, 21 Dec 2016 13:47:13 -0500
In pg_dump.c dumpCast() and dumpTransform(), we would happily ignore the
cast or transform if it happened to use a built-in function because we
weren't including the information about built-in functions when querying
pg_proc from getFuncs().
Modify the query in getFuncs() to also gather information about
functions which are used by user-defined casts and transforms (where
"user-defined" means "has an OID >= FirstNormalObjectId"). This also
adds to the TAP regression tests for 9.6 and master to cover these
types of objects.
Back-patch all the way for casts, back to 9.5 for transforms.
Discussion: https://www.postgresql.org/message-id/flat/20160504183952.GE10850%40tamriel.snowman.net
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/t/002_pg_dump.pl
For 8.0 servers, get last built-in oid from pg_database
commit : e45319bb7796e3ab8095da329a1f73d22aaa57c4
author : Stephen Frost <sfrost@snowman.net>
date : Wed, 21 Dec 2016 13:47:13 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Wed, 21 Dec 2016 13:47:13 -0500
We didn't start ensuring that all built-in objects had OIDs less than
16384 until 8.1, so for 8.0 servers we still need to query the value out
of pg_database. We need this, in particular, to distinguish which casts
were built-in and which were user-defined.
For HEAD, we only worry about going back to 8.0, for the back-branches,
we also ensure that 7.0-7.4 work.
Discussion: https://www.postgresql.org/message-id/flat/20160504183952.GE10850%40tamriel.snowman.net
M src/bin/pg_dump/pg_dump.c
Fix order of operations in CREATE OR REPLACE VIEW.
commit : a46ee6b30ae9cba3ece5b4b5912969c74969f274
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Wed, 21 Dec 2016 17:01:52 +0000
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Wed, 21 Dec 2016 17:01:52 +0000
When CREATE OR REPLACE VIEW acts on an existing view, don't update the
view options until after the view query has been updated.
This is necessary in the case where CREATE OR REPLACE VIEW is used on
an existing view that is not updatable, and the new view is updatable
and specifies the WITH CHECK OPTION. In this case, attempting to apply
the new options to the view before updating its query fails, because
the options are applied using the ALTER TABLE infrastructure which
checks that WITH CHECK OPTION is only applied to an updatable view.
If new columns are being added to the view, that is also done using
the ALTER TABLE infrastructure, but it is important that that still be
done before updating the view query, because the rules system checks
that the query columns match those on the view relation. Added a
comment to explain that, in case someone is tempted to move that to
where the view options are now being set.
Back-patch to 9.4 where WITH CHECK OPTION was added.
Report: https://postgr.es/m/CAEZATCUp%3Dz%3Ds4SzZjr14bfct_bdJNwMPi-gFi3Xc5k1ntbsAgQ%40mail.gmail.com
M src/backend/commands/view.c
M src/test/regress/expected/updatable_views.out
M src/test/regress/sql/updatable_views.sql
Fix corner-case bug in WaitEventSetWaitBlock on Windows.
commit : b98e5513f33154ede701963ee9115ea056e9dea9
author : Robert Haas <rhaas@postgresql.org>
date : Wed, 21 Dec 2016 11:01:48 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Wed, 21 Dec 2016 11:01:48 -0500
If we do not reset the FD_READ event, WaitForMultipleObjects won't
return it again again unless we've meanwhile read from the socket,
which is generally true but not guaranteed. WaitEventSetWaitBlock
itself may fail to return the event to the caller if the latch is
also set, and even if we changed that, the caller isn't obliged to
handle all returned events at once. On non-Windows systems, the
socket-read event is purely level-triggered, so this issue does
not exist. To fix, make Windows reset the event when needed.
This bug was introduced by 98a64d0bd713cb89e61bef6432befc4b7b5da59e,
and causes hangs when trying to use the pldebugger extension.
Patch by Amit Kapial. Reported and tested by Ashutosh Sharma, who
also provided some analysis. Further analysis by Michael Paquier.
M src/backend/storage/ipc/latch.c
M src/include/storage/latch.h
Fix sharing Agg transition state of DISTINCT or ordered aggs.
commit : ce92fc4e2540d0ce554e498adb27f0ef29199b94
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 20 Dec 2016 09:20:17 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 20 Dec 2016 09:20:17 +0200
If a query contained two aggregates that could share the transition value,
we would correctly collect the input into a tuplesort only once, but
incorrectly run the transition function over the accumulated input twice,
in finalize_aggregates(). That caused a crash, when we tried to call
tuplesort_performsort() on an already-freed NULL tuplestore.
Backport to 9.6, where sharing of transition state and this bug were
introduced.
Analysis by Tom Lane.
Discussion: https://www.postgresql.org/message-id/ac5b0b69-744c-9114-6218-8300ac920e61@iki.fi
M src/backend/executor/nodeAgg.c
M src/test/regress/expected/aggregates.out
M src/test/regress/sql/aggregates.sql
Fix handling of phrase operator removal while removing tsquery stopwords.
commit : 3f07eff104793cfd82bfd3e093991695221abfd8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 19 Dec 2016 13:49:45 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 19 Dec 2016 13:49:45 -0500
The distance of a removed phrase operator should propagate up to a
parent phrase operator if there is one, but this only worked correctly
in left-deep trees. Throwing in a few parentheses confused it completely,
as indeed was illustrated by bizarre results in existing regression test
cases.
To fix, track unaccounted-for distances that should propagate to the left
and to the right of the current node, rather than trying to make it work
with only one returned distance.
Also make some adjustments to behave as well as we can for cases of
intermixed phrase and regular (AND/OR) operators. I don't think it's
possible to be 100% correct for that without a rethinking of the tsquery
representation; for example, maybe we should just not drop stopword nodes
at all underneath phrase operators. But this is better than it was,
and changing tsquery representation wouldn't be safely back-patchable.
While at it, I simplified the API of the clean_fakeval_intree function
a bit by getting rid of the "char *result" output parameter; that wasn't
doing anything that wasn't redundant with whether the result node is
NULL or not, and testing for NULL seems a lot clearer/safer.
This is part of a larger project to fix various infelicities in the
phrase-search implementation, but this part seems comittable on its own.
Back-patch to 9.6 where phrase operators were introduced.
Discussion: https://postgr.es/m/28215.1481999808@sss.pgh.pa.us
Discussion: https://postgr.es/m/26706.1482087250@sss.pgh.pa.us
M src/backend/utils/adt/tsquery_cleanup.c
M src/test/regress/expected/tsearch.out
Fix base backup rate limiting in presence of slow i/o
commit : 1c8ad594e5cb46952bd70f8a0f2f8681912dc223
author : Magnus Hagander <magnus@hagander.net>
date : Mon, 19 Dec 2016 10:11:04 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Mon, 19 Dec 2016 10:11:04 +0100
When source i/o on disk was too slow compared to the rate limiting
specified, the system could end up with a negative value for sleep that
it never got out of, which caused rate limiting to effectively be
turned off.
Discussion: https://postgr.es/m/CABUevEy_-e0YvL4ayoX8bH_Ja9w%2BBHoP6jUgdxZuG2nEj3uAfQ%40mail.gmail.com
Analysis by me, patch by Antonin Houska
M src/backend/replication/basebackup.c
In contrib/uuid-ossp, #include headers needed for ntohl() and ntohs().
commit : 512f27cb3576d1ee1cb9a20463a33bd678e72db8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 17 Dec 2016 22:24:13 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 17 Dec 2016 22:24:13 -0500
Oversight in commit b8cc8f947. I just noticed this causes compiler
warnings on FreeBSD, and it really ought to cause warnings elsewhere too:
all references I can find say that <arpa/inet.h> is required for these.
We have a lot of code elsewhere that thinks that both <netinet/in.h>
and <arpa/inet.h> should be included for these functions, so do it that
way here too, even though <arpa/inet.h> ought to be sufficient according
to the references I consulted.
Back-patch to 9.4 where the previous commit landed.
M contrib/uuid-ossp/uuid-ossp.c
Fix FK-based join selectivity estimation for semi/antijoins.
commit : f4f195d15c7cefb0d6435028c23b523d671c1ec7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 17 Dec 2016 15:28:54 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 17 Dec 2016 15:28:54 -0500
This case wasn't thought through sufficiently in commit 100340e2d.
It's true that the FK proves that every outer row has a match in the
inner table, but we forgot that some of the inner rows might be filtered
away by WHERE conditions located within the semijoin's RHS.
If the RHS is just one table, we can reasonably take the semijoin
selectivity as equal to the fraction of the referenced table's rows
that are expected to survive its restriction clauses.
If the RHS is a join, it's not clear how much of the referenced table
might get through the join, so fall back to the same rule we were
already using for other outer-join cases: use the minimum of the
regular per-clause selectivity estimates. This gives the same result
as if we hadn't considered the FK at all when there's a single FK
column, but it should still help for multi-column FKs, which is the
case that 100340e2d is really meant to help with.
Back-patch to 9.6 where the previous commit came in.
Discussion: https://postgr.es/m/16149.1481835103@sss.pgh.pa.us
M src/backend/optimizer/path/costsize.c
Ensure that num_sync is greater than zero in synchronous_standby_names.
commit : 6c75fb6b3dbeda4dac19cee8f2d5cc7f38f362ee
author : Fujii Masao <fujii@postgresql.org>
date : Sat, 17 Dec 2016 02:20:59 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Sat, 17 Dec 2016 02:20:59 +0900
Previously num_sync could be set to zero and this setting caused
an assertion failure. This means that multiple synchronous standbys
code should assume that num_sync is greater than zero.
Also setting num_sync to zero is nonsense because it's basically
the configuration for synchronous replication. If users want not to
make transaction commits wait for any standbys,
synchronous_standby_names should be emptied to disable synchronous
replication instead of setting num_sync to zero.
This patch forbids users from setting num_sync to zero in
synchronous_standby_names. If zero is specified, an error will
happen during processing the parameter settings.
Back-patch to 9.6 where multiple synchronous standbys feature was added.
Patch by me. Reviewed by Tom Lane.
Discussion: <CAHGQGwHWB3izc6cXuFLh5kOcAbFXaRhhgwd-X5PeN9TEjxqXwg@mail.gmail.com>
M src/backend/replication/syncrep.c
Improve documentation around TS_execute().
commit : 6f734554c38811316a9d6951b4500a6d1b0b84aa
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 Dec 2016 11:50:07 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 16 Dec 2016 11:50:07 -0500
I got frustrated by the lack of commentary in this area, so here is some
reverse-engineered documentation, along with minor stylistic cleanup.
No code changes more significant than removal of unused variables.
Back-patch to 9.6, not because that's useful in itself, but because
we have some bugs to fix in phrase search and this would cause merge
failures if it's only in HEAD.
M src/backend/tsearch/wparser_def.c
M src/backend/utils/adt/tsginidx.c
M src/backend/utils/adt/tsvector_op.c
M src/include/tsearch/ts_utils.h
Add missing documentation for effective_io_concurrency tablespace option.
commit : b344b879d3d3880b21c44687a3fe09e81e9ad3a9
author : Fujii Masao <fujii@postgresql.org>
date : Sat, 17 Dec 2016 01:25:29 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Sat, 17 Dec 2016 01:25:29 +0900
The description of effective_io_concurrency option was missing in ALTER
TABLESPACE docs though it's included in CREATE TABLESPACE one.
Back-patch to 9.6 where effective_io_concurrency tablespace option was added.
Michael Paquier, reported by Marc-Olaf Jaschke
M doc/src/sgml/ref/alter_tablespace.sgml
Fix off-by-one in memory allocation for quote_literal_cstr().
commit : 0fe5a4cd7579289ac8b73feb61f72ef9e6995200
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 16 Dec 2016 12:50:20 +0200
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 16 Dec 2016 12:50:20 +0200
The calculation didn't take into account the NULL terminator. That lead
to overwriting the palloc'd buffer by one byte, if the input consists
entirely of backslashes. For example "format('%L', E'\\')".
Fixes bug #14468. Backpatch to all supported versions.
Report: https://www.postgresql.org/message-id/20161216105001.13334.42819%40wrigleys.postgresql.org
M src/backend/utils/adt/quote.c
Sync our copy of the timezone library with IANA release tzcode2016j.
commit : 6f4d38dbe06867df01dd62b52dae1654eba3976f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 15 Dec 2016 14:32:42 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 15 Dec 2016 14:32:42 -0500
This is a trivial update (consisting in fact only in the addition of
a comment). The point is just to get back to being synced with an
official release of tzcode, rather than some ad-hoc point in their
commit history, which is where commit 1f87181e1 left it.
M src/timezone/README
M src/timezone/zic.c
Prevent planagg.c from failing on queries containing CTEs.
commit : 997a2994eef372d06798d2f3409a76098c1590a1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 13 Dec 2016 13:20:16 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 13 Dec 2016 13:20:16 -0500
The existing tests in preprocess_minmax_aggregates() usually prevent it
from trying to do anything with queries containing CTEs, but there's an
exception: a CTE could be present as a member of an appendrel, if we
flattened a UNION ALL that contains CTE references. If it did try to
generate an optimized path for a query using a CTE, it failed with
"could not find plan for CTE", as reported by Torsten Förtsch.
The proximate cause is an unwise decision in commit 3fc6e2d7f to clear
subroot->cte_plan_ids in build_minmax_path(). That left the subroot's
cte_plan_ids list out of step with its parse->cteList.
Removing the "subroot->cte_plan_ids = NIL;" assignment is enough to let
the case work again, but really it's pretty silly to be expending any
cycles at all in this module when there are CTEs: we always treat their
outputs as unordered so there's no way for the optimization to win.
Hence, also add an early-exit test so we don't waste time like that.
Back-patch to 9.6 where the misbehavior was introduced.
Report: https://postgr.es/m/CAKkG4_=gjY5QiHtqSZyWMwDuTd_CftKoTaCqxjJ7uUz1-Gw=qw@mail.gmail.com
M src/backend/optimizer/plan/planagg.c
doc: Fix purported type of pg_am.amhandler to match reality.
commit : ace0df9345c9fe61570348f2a5c3324a726fd4fa
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 12 Dec 2016 13:43:48 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 12 Dec 2016 13:43:48 -0500
Joel Jacobson
M doc/src/sgml/catalogs.sgml
Use "%option prefix" to set API names in ecpg's lexer.
commit : 89d1dfa49aaff7c0b90de2c91dbb314e1a57eb62
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 11 Dec 2016 14:54:25 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 11 Dec 2016 14:54:25 -0500
Clean up some technical debt left behind by commit 72b1e3a21: instead of
quickly hacking the name of base_yylex() with a #define, set it properly
with "%option prefix". This causes the names of pgc.l's other exported
symbols to change as well, so run around and modify the outside references
to them as needed. Similarly, make pgc.l's external references to
base_yylval use that variable's true name instead of a macro.
The reason for doing this now is that the quick-hack solution will fail
with future versions of flex, as reported by Дилян Палаузов.
Hence, back-patch into 9.6 where the previous commit appeared, since
it's likely people will build 9.6 with newer flex versions during
its lifetime.
Discussion: https://postgr.es/m/d845c1af-e18d-6651-178f-9f08cdf37e10@aegee.org
M src/interfaces/ecpg/preproc/descriptor.c
M src/interfaces/ecpg/preproc/ecpg.addons
M src/interfaces/ecpg/preproc/ecpg.c
M src/interfaces/ecpg/preproc/ecpg.header
M src/interfaces/ecpg/preproc/ecpg.trailer
M src/interfaces/ecpg/preproc/extern.h
M src/interfaces/ecpg/preproc/output.c
M src/interfaces/ecpg/preproc/parser.c
M src/interfaces/ecpg/preproc/pgc.l
M src/interfaces/ecpg/preproc/variable.c
Prevent crash when ts_rewrite() replaces a non-top-level subtree with null.
commit : c8bfe055be9c688d7084546245c59f7f12a7c606
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 11 Dec 2016 13:09:57 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 11 Dec 2016 13:09:57 -0500
When ts_rewrite()'s replacement argument is an empty tsquery, it's supposed
to simplify any operator nodes whose operand(s) become NULL; but it failed
to do that reliably, because dropvoidsubtree() only examined the top level
of the result tree. Rather than make a second recursive pass, let's just
give the responsibility to dofindsubquery() to simplify while it's doing
the main replacement pass. Per report from Andreas Seltenreich.
Artur Zakirov, with some cosmetic changes by me. Back-patch to all
supported branches.
Discussion: https://postgr.es/m/8737i01dew.fsf@credativ.de
M src/backend/utils/adt/tsquery_rewrite.c
M src/test/regress/expected/tsearch.out
M src/test/regress/sql/tsearch.sql
Be more careful about Python refcounts while creating exception objects.
commit : b90f2247e1fca1e4c55fbbbfbf9354e3864f3fbc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 Dec 2016 15:27:23 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 Dec 2016 15:27:23 -0500
PLy_generate_spi_exceptions neglected to do Py_INCREF on the new exception
objects, evidently supposing that PyModule_AddObject would do that --- but
it doesn't. This left us in a situation where a Python garbage collection
cycle could result in deletion of exception object(s), causing server
crashes or wrong answers if the exception objects are used later in the
session.
In addition, PLy_generate_spi_exceptions didn't bother to test for
a null result from PyErr_NewException, which at best is inconsistent
with the code in PLy_add_exceptions. And PLy_add_exceptions, while it
did do Py_INCREF on the exceptions it makes, waited to do that till
after some PyModule_AddObject calls, creating a similar risk for
failure if garbage collection happened within those calls.
To fix, refactor to have just one piece of code that creates an
exception object and adds it to the spiexceptions module, bumping the
refcount first.
Also, let's add an additional refcount to represent the pointer we're
going to store in a C global variable or hash table. This should only
matter if the user does something weird like delete the spiexceptions
Python module, but lack of paranoia has caused us enough problems in
PL/Python already.
The fact that PyModule_AddObject doesn't do a Py_INCREF of its own
explains the need for the Py_INCREF added in commit 4c966d920, so we
can improve the comment about that; also, this means we really want
to do that before not after the PyModule_AddObject call.
The missing Py_INCREF in PLy_generate_spi_exceptions was reported and
diagnosed by Rafa de la Torre; the other fixes by me. Back-patch
to all supported branches.
Discussion: https://postgr.es/m/CA+Fz15kR1OXZv43mDrJb3XY+1MuQYWhx5kx3ea6BRKQp6ezGkg@mail.gmail.com
M src/pl/plpython/plpy_plpymodule.c
Fix reporting of column typmods for multi-row VALUES constructs.
commit : cf22c8cb8900e09615e3791590507f1edef8dd97
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 Dec 2016 12:01:14 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 Dec 2016 12:01:14 -0500
expandRTE() and get_rte_attribute_type() reported the exprType() and
exprTypmod() values of the expressions in the first row of the VALUES as
being the column type/typmod returned by the VALUES RTE. That's fine for
the data type, since we coerce all expressions in a column to have the same
common type. But we don't coerce them to have a common typmod, so it was
possible for rows after the first one to return values that violate the
claimed column typmod. This leads to the incorrect result seen in bug
#14448 from Hassan Mahmood, as well as some other corner-case misbehaviors.
The desired behavior is the same as we use in other type-unification
cases: report the common typmod if there is one, but otherwise return -1
indicating no particular constraint.
We fixed this in HEAD by deriving the typmods during transformValuesClause
and storing them in the RTE, but that's not a feasible solution in the back
branches. Instead, just use a brute-force approach of determining the
correct common typmod during expandRTE() and get_rte_attribute_type().
Simple testing says that that doesn't really cost much, at least not in
common cases where expandRTE() is only used once per query. It turns out
that get_rte_attribute_type() is typically never used at all on VALUES
RTEs, so the inefficiency there is of no great concern.
Report: https://postgr.es/m/20161205143037.4377.60754@wrigleys.postgresql.org
Discussion: https://postgr.es/m/27429.1480968538@sss.pgh.pa.us
M src/backend/parser/parse_relation.c
M src/test/regress/expected/create_view.out
M src/test/regress/sql/create_view.sql
Fix crasher bug in array_position(s)
commit : 79c89f1f4e939b7a3f3bb4a76476dcda651cd58b
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 9 Dec 2016 12:42:17 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 9 Dec 2016 12:42:17 -0300
array_position and its cousin array_positions were caching the element
type equality function's FmgrInfo without being careful enough to put it
in a long-lived context. This is obviously broken but it didn't matter
in most cases; only when using arrays of records (involving record_eq)
it becomes a problem. The fix is to ensure that the type's equality
function's FmgrInfo is cached in the array_position's flinfo->fn_mcxt
rather than the current memory context.
Apart from record types, the only other case that seems complex enough
to possibly cause the same problem are range types. I didn't find a way
to reproduce the problem with those, so I only include the test case
submitted with the bug report as regression test.
Bug report and patch: Junseok Yang
Discussion: https://postgr.es/m/CAE+byMupUURYiZ6bKYgMZb9pgV1CYAijJGqWj-90W=nS7uEOeA@mail.gmail.com
Backpatch to 9.5, where array_position appeared.
M src/backend/utils/adt/array_userfuncs.c
M src/test/regress/expected/arrays.out
M src/test/regress/sql/arrays.sql
Fix bogus comment.
commit : 86c6aaff6ead3e00a89fd0743195678bbc69790c
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 8 Dec 2016 14:59:46 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 8 Dec 2016 14:59:46 -0500
Commit 4212cb73262bbdd164727beffa4c4744b4ead92d rendered a comment
in execMain.c incorrect. Per complaint from Tom Lane, repair.
Patch from Amit Kapila, per wording suggested by Tom Lane and me.
M src/backend/executor/execMain.c
Log the creation of an init fork unconditionally.
commit : 1ed3c6ff9ef411771d4a9fc9a82c3adea0d6ab3b
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 8 Dec 2016 14:09:09 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 8 Dec 2016 14:09:09 -0500
Previously, it was thought that this only needed to be done for the
benefit of possible standbys, so wal_level = minimal skipped it.
But that's not safe, because during crash recovery we might replay
XLOG_DBASE_CREATE or XLOG_TBLSPC_CREATE record which recursively
removes the directory that contains the new init fork. So log it
always.
The user-visible effect of this bug is that if you create a database
or tablespace, then create an unlogged table, then crash without
checkpointing, then restart, accessing the table will fail, because
the it won't have been properly reset. This commit fixes that.
Michael Paquier, per a report from Konstantin Knizhnik. Wording of
the comments per a suggestion from me.
M contrib/bloom/blinsert.c
M src/backend/access/nbtree/nbtree.c
M src/backend/access/spgist/spginsert.c
M src/backend/catalog/heap.c
Restore psql's SIGPIPE setting if popen() fails.
commit : 29babe981cba76d934aa4936ca393ddd2894c4e7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 7 Dec 2016 12:39:24 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 7 Dec 2016 12:39:24 -0500
Ancient oversight in PageOutput(): if popen() fails, we'd better reset
the SIGPIPE handler before returning stdout, because ClosePager() won't.
Noticed while fixing the empty-PAGER issue.
M src/fe_utils/print.c
Handle empty or all-blank PAGER setting more sanely in psql.
commit : bb39f58f76b43bf0ef234e1baaf824e2cb9c9210
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 7 Dec 2016 12:19:56 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 7 Dec 2016 12:19:56 -0500
If the PAGER environment variable is set but contains an empty string,
psql would pass it to "sh" which would silently exit, causing whatever
query output we were printing to vanish entirely. This is quite
mystifying; it took a long time for us to figure out that this was the
cause of Joseph Brenner's trouble report. Rather than allowing that
to happen, we should treat this as another way to specify "no pager".
(We could alternatively treat it as selecting the default pager, but
it seems more likely that the former is what the user meant to achieve
by setting PAGER this way.)
Nonempty, but all-white-space, PAGER values have the same behavior, and
it's pretty easy to test for that, so let's handle that case the same way.
Most other cases of faulty PAGER values will result in the shell printing
some kind of complaint to stderr, which should be enough to diagnose the
problem, so we don't need to work harder than this. (Note that there's
been an intentional decision not to be very chatty about apparent failure
returns from the pager process, since that may happen if, eg, the user
quits the pager with control-C or some such. I'd just as soon not start
splitting hairs about which exit codes might merit making our own report.)
libpq's old PQprint() function was already on board with ignoring empty
PAGER values, but for consistency, make it ignore all-white-space values
as well.
It's been like this a long time, so back-patch to all supported branches.
Discussion: https://postgr.es/m/CAFfgvXWLOE2novHzYjmQK8-J6TmHz42G8f3X0SORM44+stUGmw@mail.gmail.com
M doc/src/sgml/ref/psql-ref.sgml
M src/fe_utils/print.c
M src/interfaces/libpq/fe-print.c
Fix unsafe assumption that struct timeval.tv_sec is a "long".
commit : 81f3c20a65e683ee235a5d3aa6146db84eb75ebf
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 Dec 2016 19:52:34 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 Dec 2016 19:52:34 -0500
It typically is a "long", but it seems possible that on some platforms
it wouldn't be. In any case, this silences a compiler warning on
OpenBSD (cf buildfarm member curculio).
While at it, use snprintf not sprintf. This format string couldn't
possibly overrun the supplied buffer, but that doesn't seem like
a good reason not to use the safer style.
Oversight in commit f828654e1. Back-patch to 9.6 where that came in.
M src/backend/utils/error/elog.c
Fix interaction of parallel query with prepared statements.
commit : ebe5dc9e02a6464713bd48e266eee48351d23062
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 6 Dec 2016 11:11:54 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 6 Dec 2016 11:11:54 -0500
Previously, a prepared statement created via a Parse message could get
a parallel plan, but one created with a PREPARE statement could not.
This state of affairs was due to confusion on my (rhaas) part: I
erroneously believed that a CREATE TABLE .. AS EXECUTE statement could
only be performed with a prepared statement by PREPARE, but in fact
one created by a Prepare message works just as well. Therefore, it
makes no sense to allow parallel query in one case but not the other.
To fix, allow parallel query with all prepared statements, but run
the parallel plan serially (i.e. without workers) in the case of
CREATE TABLE .. AS EXECUTE. Also, document this.
Amit Kapila and Tobias Bussman, plus an extra sentence of
documentation by me.
M doc/src/sgml/parallel.sgml
M src/backend/commands/prepare.c
M src/backend/executor/execMain.c
Revert "Permit dump/reload of not-too-large >1GB tuples"
commit : e9e44a0953fa4ca54ace9500596c2ef930dbd1de
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 6 Dec 2016 12:36:44 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 6 Dec 2016 12:36:44 -0300
This reverts commit 4e01ecae98275298c680c92fdba62daf603dc98e.
Per Tom Lane, changing the definition of StringInfoData amounts to an
ABI break, which is unacceptable in back branches.
M src/backend/access/common/heaptuple.c
M src/backend/commands/copy.c
M src/backend/lib/stringinfo.c
M src/include/lib/stringinfo.h
Ensure gatherstate->nextreader is properly initialized.
commit : 06fa6670fb6bf430739cb1f69d28429a0e24851f
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 5 Dec 2016 15:54:28 -0500
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 5 Dec 2016 15:54:28 -0500
The previously code worked OK as long as a Gather node was never
rescanned, or if it was rescanned, as long as it got at least as
many workers on rescan as it had originally. But if the number
of workers ever decreased on a rescan, then it could crash.
Andreas Seltenreich
M src/backend/executor/nodeGather.c
Fix typo in docs.
commit : efeb3135061dd45d3882eadd878ac09943d0362a
author : Fujii Masao <fujii@postgresql.org>
date : Mon, 5 Dec 2016 20:44:21 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Mon, 5 Dec 2016 20:44:21 +0900
Reported-by: Darko Prelec
M doc/src/sgml/parallel.sgml
Fix incorrect output from gin_desc().
commit : 71267066e95be2906a0224b19f548b57b46db91d
author : Fujii Masao <fujii@postgresql.org>
date : Mon, 5 Dec 2016 20:29:41 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Mon, 5 Dec 2016 20:29:41 +0900
Previously gin_desc() displayed incorrect output "unknown action 0"
for XLOG_GIN_INSERT and XLOG_GIN_VACUUM_DATA_LEAF_PAGE records with
valid actions. The cause of this problem was that gin_desc() wrongly
used XLogRecGetData() to extract data from those records.
Since they were registered by XLogRegisterBufData(), gin_desc() should
have used XLogRecGetBlockData(), instead, like gin_redo().
Also there were other differences about how to treat XLOG_GIN_INSERT
record between gin_desc() and gin_redo().
This commit fixes gin_desc() routine so that it treats those records
in the same way as gin_redo().
Batch-patch to 9.5 where WAL record format was revamped and
XLogRegisterBufData() was added.
Reported-By: Andres Freund
Reviewed-By: Tom Lane
Discussion: <20160509194645.7lewnpw647zegx2m@alap3.anarazel.de>
M src/backend/access/rmgrdesc/gindesc.c
Don't mess up pstate->p_next_resno in transformOnConflictClause().
commit : da05d0ebc637a84ba41a172b32552557ebad199f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Dec 2016 15:02:27 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Dec 2016 15:02:27 -0500
transformOnConflictClause incremented p_next_resno while generating the
phony targetlist for the EXCLUDED pseudo-rel. Then that field got
incremented some more during transformTargetList, possibly leading to
free_parsestate concluding that we'd overrun the allowed length of a tlist,
as reported by Justin Pryzby.
We could fix this by resetting p_next_resno to 1 after using it for the
EXCLUDED pseudo-rel tlist, but it seems easier and less coupled to other
places if we just don't use that field at all in this loop. (Note that
this doesn't change anything about the resnos that end up appearing in
the main target list, because those are all replaced with target-column
numbers by updateTargetListEntry.)
In passing, fix incorrect type OID assigned to the whole-row Var for
"EXCLUDED.*" (somehow this escaped having any bad consequences so far,
but it's certainly wrong); remove useless assignment to var->location;
pstrdup the column names in case of a relcache flush; and improve
nearby comments.
Back-patch to 9.5 where ON CONFLICT was introduced.
Report: https://postgr.es/m/20161204163237.GA8030@telsasoft.com
M src/backend/parser/analyze.c
Make pgwin32_putenv() visit debug CRTs.
commit : 784054579b7d043a35a5af92da462a3e0f53750f
author : Noah Misch <noah@leadboat.com>
date : Sat, 3 Dec 2016 15:46:36 -0500
committer: Noah Misch <noah@leadboat.com>
date : Sat, 3 Dec 2016 15:46:36 -0500
This has no effect in the most conventional case, where no relevant DLL
uses a debug build. For an example where it does matter, given a debug
build of MIT Kerberos, the krb_server_keyfile parameter usually had no
effect. Since nobody wants a Heisenbug, back-patch to 9.2 (all
supported versions).
Christian Ullrich, reviewed by Michael Paquier.
M src/port/win32env.c
Remove wrong CloseHandle() call.
commit : 056d62c5e5bd5c3c70952aa9e361fe7d7ea26d66
author : Noah Misch <noah@leadboat.com>
date : Sat, 3 Dec 2016 15:46:35 -0500
committer: Noah Misch <noah@leadboat.com>
date : Sat, 3 Dec 2016 15:46:35 -0500
In accordance with its own documentation, invoke CloseHandle() only when
directed in the documentation for the function that furnished the
handle. GetModuleHandle() does not so direct. We have been issuing
this call only in the rare event that a CRT DLL contains no "_putenv"
symbol, so lack of bug reports is uninformative. Back-patch to 9.2 (all
supported versions).
Christian Ullrich, reviewed by Michael Paquier.
M src/port/win32env.c
Refine win32env.c cosmetics.
commit : d66dcb4ca5553c43149a876265aebeb58076c0f1
author : Noah Misch <noah@leadboat.com>
date : Sat, 3 Dec 2016 15:46:35 -0500
committer: Noah Misch <noah@leadboat.com>
date : Sat, 3 Dec 2016 15:46:35 -0500
Replace use of plain 0 as a null pointer constant. In comments, update
terminology and lessen redundancy. Back-patch to 9.2 (all supported
versions) for the convenience of back-patching the next two commits.
Christian Ullrich and Noah Misch, reviewed (in earlier versions) by
Michael Paquier.
M src/port/win32env.c
Permit dump/reload of not-too-large >1GB tuples
commit : 4e01ecae98275298c680c92fdba62daf603dc98e
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 2 Dec 2016 00:34:01 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 2 Dec 2016 00:34:01 -0300
Our documentation states that our maximum field size is 1 GB, and that
our maximum row size of 1.6 TB. However, while this might be attainable
in theory with enough contortions, it is not workable in practice; for
starters, pg_dump fails to dump tables containing rows larger than 1 GB,
even if individual columns are well below the limit; and even if one
does manage to manufacture a dump file containing a row that large, the
server refuses to load it anyway.
This commit enables dumping and reloading of such tuples, provided two
conditions are met:
1. no single column is larger than 1 GB (in output size -- for bytea
this includes the formatting overhead)
2. the whole row is not larger than 2 GB
There are three related changes to enable this:
a. StringInfo's API now has two additional functions that allow creating
a string that grows beyond the typical 1GB limit (and "long" string).
ABI compatibility is maintained. We still limit these strings to 2 GB,
though, for reasons explained below.
b. COPY now uses long StringInfos, so that pg_dump doesn't choke
trying to emit rows longer than 1GB.
c. heap_form_tuple now uses the MCXT_ALLOW_HUGE flag in its allocation
for the input tuple, which means that large tuples are accepted on
input. Note that at this point we do not apply any further limit to the
input tuple size.
The main reason to limit to 2 GB is that the FE/BE protocol uses 32 bit
length words to describe each row; and because the documentation is
ambiguous on its signedness and libpq does consider it signed, we cannot
use the highest-order bit. Additionally, the StringInfo API uses "int"
(which is 4 bytes wide in most platforms) in many places, so we'd need
to change that API too in order to improve, which has lots of fallout.
Backpatch to 9.5, which is the oldest that has
MemoryContextAllocExtended, a necessary piece of infrastructure. We
could apply to 9.4 with very minimal additional effort, but any further
than that would require backpatching "huge" allocations too.
This is the largest set of changes we could find that can be
back-patched without breaking compatibility with existing systems.
Fixing a bigger set of problems (for example, dumping tuples bigger than
2GB, or dumping fields bigger than 1GB) would require changing the FE/BE
protocol and/or changing the StringInfo API in an ABI-incompatible way,
neither of which would be back-patchable.
Authors: Daniel Vérité, Álvaro Herrera
Reviewed by: Tomas Vondra
Discussion: https://postgr.es/m/20160229183023.GA286012@alvherre.pgsql
M src/backend/access/common/heaptuple.c
M src/backend/commands/copy.c
M src/backend/lib/stringinfo.c
M src/include/lib/stringinfo.h
Doc: improve description of trim() and related functions.
commit : dd3edfe630fecd561568455a2c47ec5858a95e8c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Nov 2016 13:34:14 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 30 Nov 2016 13:34:14 -0500
Per bug #14441 from Mark Pether, the documentation could be misread,
mainly because some of the examples failed to show what happens with
a multicharacter "characters to trim" string. Also, while the text
description in most of these entries was fairly clear that the
"characters" argument is a set of characters not a substring to match,
some of them used variant wording that was a bit less clear.
trim() itself suffered from both deficiencies and was thus pretty
misinterpretable.
Also fix failure to explain which of LEADING/TRAILING/BOTH is the
default.
Discussion: https://postgr.es/m/20161130011710.6539.53657@wrigleys.postgresql.org
M doc/src/sgml/func.sgml
Fix bogus handling of JOIN_UNIQUE_OUTER/INNER cases for parallel joins.
commit : e5b8aa636a63a9446e244fcc8d3a262e3e14049a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Nov 2016 19:32:35 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Nov 2016 19:32:35 -0500
consider_parallel_nestloop passed the wrong jointype down to its
subroutines for JOIN_UNIQUE_INNER cases (it should pass JOIN_INNER), and it
thought that it could pass paths other than innerrel->cheapest_total_path
to create_unique_path, which create_unique_path is not on board with.
These bugs would lead to assertion failures or other errors, suggesting
that this code path hasn't been tested much.
hash_inner_and_outer's code for parallel join effectively treated both
JOIN_UNIQUE_OUTER and JOIN_UNIQUE_INNER the same as JOIN_INNER (for
different reasons :-(), leading to incorrect plans that treated a semijoin
as if it were a plain join.
Michael Day submitted a test case demonstrating that hash_inner_and_outer
failed for JOIN_UNIQUE_OUTER, and I found the other cases through code
review.
Report: https://postgr.es/m/D0E8A029-D1AC-42E8-979A-5DE4A77E4413@rcmail.com
M src/backend/optimizer/path/joinpath.c
Fix incorrect variable type in set_rel_consider_parallel().
commit : 0c65061de26470f2b17e3856fd2afd6c266195b7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Nov 2016 11:07:02 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 29 Nov 2016 11:07:02 -0500
func_parallel() returns char not Oid. Harmless, but still wrong.
Amit Langote
M src/backend/optimizer/path/allpaths.c
Clarify pg_dump -b documentation
commit : d722927e1f0ce13a289c3dd8106265d27ca25c3b
author : Stephen Frost <sfrost@snowman.net>
date : Tue, 29 Nov 2016 10:35:07 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Tue, 29 Nov 2016 10:35:07 -0500
The documentation around the -b/--blobs option to pg_dump seemed to
imply that it might be possible to add blobs to a "schema-only" dump or
similar. Clarify that blobs are data and therefore will only be
included in dumps where data is being included, even when -b is used to
request blobs be included.
The -b option has been around since before 9.2, so back-patch to all
supported branches.
Discussion: https://postgr.es/m/20161119173316.GA13284@tamriel.snowman.net
M doc/src/sgml/ref/pg_dump.sgml
Correct psql documentation example
commit : 40eb468a1b2678475b648617bf5fc428739eb807
author : Stephen Frost <sfrost@snowman.net>
date : Tue, 29 Nov 2016 09:03:17 -0500
committer: Stephen Frost <sfrost@snowman.net>
date : Tue, 29 Nov 2016 09:03:17 -0500
An example in the psql documentation had an incorrect field name from
what the command actually produced.
Pointed out by Fabien COELHO
Back-patch to 9.6 where the example was added.
Discussion: https://postgr.es/m/alpine.DEB.2.20.1611291349400.19314@lancre
M doc/src/sgml/ref/psql-ref.sgml
Fix get_relation_info name typo'ed in a comment
commit : d43ff47eabda68a8d37bf795ffb96809919b09b7
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 28 Nov 2016 15:56:00 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 28 Nov 2016 15:56:00 -0300
Plus add a missing comment about this in get_relation_info itself.
Author: Amit Langote
Discussion: https://postgr.es/m/e46c0569-0449-afa0-e2fe-f3776e4b3fd5@lab.ntt.co.jp
M src/backend/optimizer/util/plancat.c
M src/backend/optimizer/util/relnode.c
Fix busted tab-completion pattern for ALTER TABLE t ALTER c DROP ...
commit : 28735cc72d992ed52df0c3d90140d914ef722639
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 28 Nov 2016 11:51:30 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 28 Nov 2016 11:51:30 -0500
Evidently a thinko in commit 9b181b036.
Kyotaro Horiguchi
M src/bin/psql/tab-complete.c
Mention server start requirement for ssl parameters
commit : 3a3ac47998ec5beb738cc7e55d7bc2cfce206661
author : Magnus Hagander <magnus@hagander.net>
date : Sun, 27 Nov 2016 17:10:02 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Sun, 27 Nov 2016 17:10:02 +0100
Fix that the documentation for three ssl related parameters did not
specify that they can only be changed at server start.
Michael Paquier
M doc/src/sgml/config.sgml
Fix test about ignoring extension dependencies during extension scripts.
commit : 0cc8453aca1c91e5bff27ec519e8c65dfd2b6fc9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 26 Nov 2016 13:31:35 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 26 Nov 2016 13:31:35 -0500
Commit 08dd23cec introduced an exception to the rule that extension member
objects can only be dropped as part of dropping the whole extension,
intending to allow such drops while running the extension's own creation or
update scripts. However, the exception was only applied at the outermost
recursion level, because it was modeled on a pre-existing check to ignore
dependencies on objects listed in pendingObjects. Bug #14434 from Philippe
Beaudoin shows that this is inadequate: in some cases we can reach an
extension member object by recursion from another one. (The bug concerns
the serial-sequence case; I'm not sure if there are other cases, but there
might well be.)
To fix, revert 08dd23cec's changes to findDependentObjects() and instead
apply the creating_extension exception regardless of stack level.
Having seen this example, I'm a bit suspicious that the pendingObjects
logic is also wrong and such cases should likewise be allowed at any
recursion level. However, changing that would interact in subtle ways
with the recursion logic (at least it would need to be moved to after the
recursing-from check). Given that the code's been like that a long time,
I'll refrain from touching it without a clear example showing it's wrong.
Back-patch to all active branches. In HEAD and 9.6, where suitable
test infrastructure exists, add a regression test case based on the
bug report.
Report: <20161125151448.6529.33039@wrigleys.postgresql.org>
Discussion: <13224.1480177514@sss.pgh.pa.us>
M src/backend/catalog/dependency.c
M src/test/modules/test_extensions/Makefile
M src/test/modules/test_extensions/expected/test_extensions.out
M src/test/modules/test_extensions/sql/test_extensions.sql
A src/test/modules/test_extensions/test_ext7–1.0–2.0.sql
A src/test/modules/test_extensions/test_ext7–1.0.sql
A src/test/modules/test_extensions/test_ext7.control
Bring some clarity to the defaults for the xxx_flush_after parameters.
commit : 255bcd27f635a1b9682e7e0dfd348b0f8b268df1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Nov 2016 18:36:10 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Nov 2016 18:36:10 -0500
Instead of confusingly stating platform-dependent defaults for these
parameters in the comments in postgresql.conf.sample (with the main
entry being a lie on Linux), teach initdb to install the correct
platform-dependent value in postgresql.conf, similarly to the way
we handle other platform-dependent defaults. This won't do anything
for existing 9.6 installations, but since it's effectively only a
documentation improvement, that seems OK.
Since this requires initdb to have access to the default values,
move the #define's for those to pg_config_manual.h; the original
placement in bufmgr.h is unworkable because that file can't be
included by frontend programs.
Adjust the default value for wal_writer_flush_after so that it is 1MB
regardless of XLOG_BLCKSZ, conforming to what is stated in both the
SGML docs and postgresql.conf. (We could alternatively make it scale
with XLOG_BLCKSZ, but I'm not sure I see the point.)
Copy-edit related SGML documentation.
Fabien Coelho and Tom Lane, per a gripe from Tomas Vondra.
Discussion: <30ebc6e3-8358-09cf-44a8-578252938424@2ndquadrant.com>
M doc/src/sgml/config.sgml
M src/backend/access/transam/xlog.c
M src/backend/utils/misc/guc.c
M src/backend/utils/misc/postgresql.conf.sample
M src/bin/initdb/initdb.c
M src/include/pg_config_manual.h
M src/include/storage/bufmgr.h
Mark a query's topmost Paths parallel-unsafe if they will have initPlans.
commit : 474de765a8003bc58f5736f626bf533147cc1e68
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Nov 2016 16:20:12 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Nov 2016 16:20:12 -0500
Andreas Seltenreich found another case where we were being too optimistic
about allowing a plan to be considered parallelizable despite it containing
initPlans. It seems like the real issue here is that if we know we are
going to tack initPlans onto the topmost Plan node for a subquery, we
had better mark that subquery's result Paths as not-parallel-safe. That
fixes this problem and allows reversion of a kluge (added in commit
7b67a0a49 and extended in f24cf960d) to not trust the parallel_safe flag
at top level.
Discussion: <874m2w4k5d.fsf@ex.ansel.ydns.eu>
M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/plan/subselect.c
Check for pending trigger events on far end when dropping an FK constraint.
commit : bf5fe7bfa0e8bdc87be94b98bbdcb26054a6b75c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Nov 2016 13:44:47 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 25 Nov 2016 13:44:47 -0500
When dropping a foreign key constraint with ALTER TABLE DROP CONSTRAINT,
we refuse the drop if there are any pending trigger events on the named
table; this ensures that we won't remove the pg_trigger row that will be
consulted by those events. But we should make the same check for the
referenced relation, else we might remove a due-to-be-referenced pg_trigger
row for that relation too, resulting in "could not find trigger NNN" or
"relation NNN has no triggers" errors at commit. Per bug #14431 from
Benjie Gillam. Back-patch to all supported branches.
Report: <20161124114911.6530.31200@wrigleys.postgresql.org>
M src/backend/commands/tablecmds.c
M src/test/regress/expected/foreign_key.out
M src/test/regress/sql/foreign_key.sql
Fix typo in comment
commit : 81f92a55c7bb920a7b915ae0e022a8488126ec22
author : Magnus Hagander <magnus@hagander.net>
date : Fri, 25 Nov 2016 13:06:19 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Fri, 25 Nov 2016 13:06:19 +0100
Thomas Munro
M src/backend/executor/execParallel.c
Fix commit_ts for FrozenXid and BootstrapXid
commit : 9b66342901f2a3845fe2b44c647bb1316220975c
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 24 Nov 2016 15:39:55 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 24 Nov 2016 15:39:55 -0300
Previously, requesting commit timestamp for transactions
FrozenTransactionId and BootstrapTransactionId resulted in an error.
But since those values can validly appear in committed tuples' Xmin,
this behavior is unhelpful and error prone: each caller would have to
special-case those values before requesting timestamp data for an Xid.
We already have a perfectly good interface for returning "the Xid you
requested is too old for us to have commit TS data for it", so let's use
that instead.
Backpatch to 9.5, where commit timestamps appeared.
Author: Craig Ringer
Discussion: https://www.postgresql.org/message-id/CAMsr+YFM5Q=+ry3mKvWEqRTxrB0iU3qUSRnS28nz6FJYtBwhJg@mail.gmail.com
M src/backend/access/transam/commit_ts.c
M src/test/modules/commit_ts/expected/commit_timestamp.out
M src/test/modules/commit_ts/expected/commit_timestamp_1.out
M src/test/modules/commit_ts/t/004_restart.pl
Make sure ALTER TABLE preserves index tablespaces.
commit : 4a5e1d3704e5922f7f457e5ccc6c4d4ac99c71db
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Nov 2016 13:45:56 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 23 Nov 2016 13:45:56 -0500
When rebuilding an existing index, ALTER TABLE correctly kept the
physical file in the same tablespace, but it messed up the pg_class
entry if the index had been in the database's default tablespace
and "default_tablespace" was set to some non-default tablespace.
This led to an inaccessible index.
Fix by fixing pg_get_indexdef_string() to always include a tablespace
clause, whether or not the index is in the default tablespace. The
previous behavior was installed in commit 537e92e41, and I think it just
wasn't thought through very clearly; certainly the possible effect of
default_tablespace wasn't considered. There's some risk in changing the
behavior of this function, but there are no other call sites in the core
code. Even if it's being used by some third party extension, it's fairly
hard to envision a usage that is okay with a tablespace clause being
appended some of the time but can't handle it being appended all the time.
Back-patch to all supported versions.
Code fix by me, investigation and test cases by Michael Paquier.
Discussion: <1479294998857-5930602.post@n3.nabble.com>
M src/backend/utils/adt/ruleutils.c
M src/test/regress/input/tablespace.source
M src/test/regress/output/tablespace.source
Doc: in back branches, don't call it a row constructor if it isn't really.
commit : 51aebcd78a4a0674737319a804ff761800fa6830
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Nov 2016 18:07:43 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Nov 2016 18:07:43 -0500
Before commit 906bfcad7, we were not actually processing the righthand
side of a multiple-column assignment in UPDATE as a row constructor:
it was just a parenthesized list of expressions. Call it that rather
than risking confusion by people who would expect the documented behaviors
of row constructors to apply.
Back-patch to 9.5; before that, the text correctly described the construct
as a "list of independent expressions".
Discussion: <16288.1479610770@sss.pgh.pa.us>
M doc/src/sgml/ref/update.sgml
Doc: improve documentation about composite-value usage.
commit : 112676f590331356d1239068260b4642bd6073f2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Nov 2016 17:56:16 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Nov 2016 17:56:16 -0500
Create a section specifically for the syntactic rules around whole-row
variable usage, such as expansion of "foo.*". This was previously
documented only haphazardly, with some critical info buried in
unexpected places like xfunc-sql-composite-functions. Per repeated
questions in different mailing lists.
Discussion: <16288.1479610770@sss.pgh.pa.us>
M doc/src/sgml/queries.sgml
M doc/src/sgml/rowtypes.sgml
M doc/src/sgml/syntax.sgml
M doc/src/sgml/xfunc.sgml
Doc: add a section in Part II concerning RETURNING.
commit : 275e8c88a49403da2f278861ba2eb021aadd269c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Nov 2016 14:02:52 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 22 Nov 2016 14:02:52 -0500
There are assorted references to RETURNING in Part II, but nothing
that would qualify as an explanation of the feature, which seems
like an oversight considering how useful it is. Add something.
Noted while looking for a place to point a cross-reference to ...
M doc/src/sgml/dml.sgml
M doc/src/sgml/queries.sgml
Make contrib/test_decoding regression tests safe for CZ locale.
commit : 292765ce3504856062270fff4b08cd12d5bd143f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Nov 2016 20:39:28 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Nov 2016 20:39:28 -0500
A little COLLATE "C" goes a long way.
Pavel Stehule, per suggestion from Craig Ringer
Discussion: <CAFj8pRA8nJZcozgxN=RMSqMmKuHVOkcGAAKPKdFeiMWGDSUDLA@mail.gmail.com>
M contrib/test_decoding/expected/spill.out
M contrib/test_decoding/sql/spill.sql
Fix PGLC_localeconv() to handle errors better.
commit : c5917067e563841d53f07a5cdd10ebec77dffc37
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Nov 2016 18:21:55 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Nov 2016 18:21:55 -0500
The code was intentionally not very careful about leaking strdup'd
strings in case of an error. That was forgivable probably, but it
also failed to notice strdup() failures, which could lead to subsequent
null-pointer-dereference crashes, since many callers unsurprisingly
didn't check for null pointers in the struct lconv fields. An even
worse problem is that it could throw error while we were setlocale'd
to a non-C locale, causing unwanted behavior in subsequent libc calls.
Rewrite to ensure that we cannot throw elog(ERROR) until after we've
restored the previous locale settings, or at least attempted to.
(I'm sorely tempted to make restore failure be a FATAL error, but
will refrain for the moment.) Having done that, it's not much more
work to ensure that we clean up strdup'd storage on the way out, too.
This code is substantially the same in all supported branches, so
back-patch all the way.
Michael Paquier and Tom Lane
Discussion: <CAB7nPqRMbGqa_mesopcn4MPyTs34eqtVEK7ELYxvvV=oqS00YA@mail.gmail.com>
M src/backend/utils/adt/pg_locale.c
Fix test for subplans in force-parallel mode.
commit : 01f08cbbc975c56cbffc8e051ee4470ab7516358
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Nov 2016 11:09:24 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 21 Nov 2016 11:09:24 -0500
We mustn't force parallel mode if the query has any subplans, since
ExecSerializePlan doesn't transmit them to workers. Testing
top_plan->initPlan is inadequate because (1) there might be initPlans
attached to lower plan nodes, and (2) non-initPlan subplans don't
work either. There's certainly room for improvement in those
restrictions, but for the moment that's what we've got.
Amit Kapila, per report from Andreas Seltenreich
Discussion: <8737im6pmh.fsf@credativ.de>
M src/backend/optimizer/plan/planner.c
Prevent multicolumn expansion of "foo.*" in an UPDATE source expression.
commit : 90f8b4be5b9c86a3a609b7cf2d8a76e0a74a75a4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 20 Nov 2016 14:26:19 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 20 Nov 2016 14:26:19 -0500
Because we use transformTargetList() for UPDATE as well as SELECT
tlists, the code accidentally tried to expand a "*" reference into
several columns. This is nonsensical, because the UPDATE syntax
provides exactly one target column to put the value into. The
immediate result was that transformUpdateTargetList() got confused
and reported "UPDATE target count mismatch --- internal error".
It seems better to treat such a reference as a plain whole-row
variable, as it would be in other contexts. (This could produce
useful results when the target column is of composite type.)
Fix by tweaking transformTargetList() to perform *-expansion only
conditionally, depending on its exprKind parameter.
Back-patch to 9.3. The problem exists further back, but a fix would be
much more invasive before that, because transformTargetList() wasn't
told what kind of list it was working on. Doesn't seem worth the
trouble given the lack of field reports. (I only noticed it because
I was checking the code while trying to improve the documentation about
how we handle "foo.*".)
Discussion: <4308.1479595330@sss.pgh.pa.us>
M src/backend/parser/parse_target.c
M src/test/regress/expected/update.out
M src/test/regress/sql/update.sql
Code review for GUC serialization/deserialization code.
commit : 272c426604e249157e99394ec1b81e9594783ab0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 19 Nov 2016 14:26:19 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 19 Nov 2016 14:26:19 -0500
The serialization code dumped core for a string-valued GUC whose value
is NULL, which is a legal state. The infrastructure isn't capable of
transmitting that state exactly, but fortunately, transmitting an empty
string instead should be close enough (compare, eg, commit e45e990e4).
The code potentially underestimated the space required to format a
real-valued variable, both because it made an unwarranted assumption that
%g output would never be longer than %e output, and because it didn't count
right even for %e format. In practice this would pretty much always be
masked by overestimates for other variables, but it's still wrong.
Also fix boundary-case error in read_gucstate, incorrect handling of the
case where guc_sourcefile is non-NULL but zero length (not clear that can
happen, but if it did, this code would get totally confused), and
confusingly useless check for a NULL result from read_gucstate.
Andreas Seltenreich discovered the core dump; other issues noted while
reading nearby code. Back-patch to 9.5 where this code was introduced.
Michael Paquier and Tom Lane
Discussion: <871sy78wno.fsf@credativ.de>
M src/backend/utils/misc/guc.c
Improve pg_dump/pg_restore --create --if-exists logic.
commit : 0eaa5118ae457ff9873a796e08adaea1bb8172f9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 17 Nov 2016 14:59:19 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 17 Nov 2016 14:59:19 -0500
Teach it not to complain if the dropStmt attached to an archive entry
is actually spelled CREATE OR REPLACE VIEW, since that will happen due to
an upcoming bug fix. Also, if it doesn't recognize a dropStmt, have it
print a WARNING and then emit the dropStmt unmodified. That seems like a
much saner behavior than Assert'ing or dumping core due to a null-pointer
dereference, which is what would happen before :-(.
Back-patch to 9.4 where this option was introduced.
Discussion: <19092.1479325184@sss.pgh.pa.us>
M src/bin/pg_dump/pg_backup_archiver.c
Avoid pin scan for replay of XLOG_BTREE_VACUUM in all cases
commit : f5d89443203480e39a6a15e64f1950c3b4d3c9a2
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 17 Nov 2016 13:31:30 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 17 Nov 2016 13:31:30 -0300
Replay of XLOG_BTREE_VACUUM during Hot Standby was previously thought to
require complex interlocking that matched the requirements on the
master. This required an O(N) operation that became a significant
problem with large indexes, causing replication delays of seconds or in
some cases minutes while the XLOG_BTREE_VACUUM was replayed.
This commit skips the “pin scan” that was previously required, by
observing in detail when and how it is safe to do so, with full
documentation. The pin scan is skipped only in replay; the VACUUM code
path on master is not touched here.
No tests included. Manual tests using an additional patch to view WAL records
and their timing have shown the change in WAL records and their handling has
successfully reduced replication delay.
This is a back-patch of commits 687f2cd7a015, 3e4b7d87988f, b60284261375
by Simon Riggs, to branches 9.4 and 9.5. No further backpatch is
possible because this depends on catalog scans being MVCC. I (Álvaro)
additionally updated a slight problem in the README, which explains why
this touches the 9.6 and master branches.
M src/backend/access/nbtree/README
Allow DOS-style line endings in ~/.pgpass files.
commit : a69e6d9a6cd9fef893f4cf5b29a9ccf1b015c317
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 15 Nov 2016 16:17:19 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 15 Nov 2016 16:17:19 -0500
On Windows, libc will mask \r\n line endings for us, since we read the
password file in text mode. But that doesn't happen on Unix. People
who share password files across both systems might have \r\n line endings
in a file they use on Unix, so as a convenience, ignore trailing \r.
Per gripe from Josh Berkus.
In passing, put the existing check for empty line somewhere where it's
actually useful, ie after stripping the newline not before.
Vik Fearing, adjusted a bit by me
Discussion: <0de37763-5843-b2cc-855e-5d0e5df25807@agliodbs.com>
M src/interfaces/libpq/fe-connect.c
Account for catalog snapshot in PGXACT->xmin updates.
commit : 8aa3e47510b969354ea02aff25d2cae7bde9cbf1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 15 Nov 2016 15:55:35 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 15 Nov 2016 15:55:35 -0500
The CatalogSnapshot was not plugged into SnapshotResetXmin()'s accounting
for whether MyPgXact->xmin could be cleared or advanced. In normal
transactions this was masked by the fact that the transaction snapshot
would be older, but during backend startup and certain utility commands
it was possible to re-use the CatalogSnapshot after MyPgXact->xmin had
been cleared, meaning that recently-deleted rows could be pruned even
though this snapshot could still see them, causing unexpected catalog
lookup failures. This effect appears to be the explanation for a recent
failure on buildfarm member piculet.
To fix, add the CatalogSnapshot to the RegisteredSnapshots heap whenever
it is valid.
In the previous logic, it was possible for the CatalogSnapshot to remain
valid across waits for client input, but with this change that would mean
it delays advance of global xmin in cases where it did not before. To
avoid possibly causing new table-bloat problems with clients that sit idle
for long intervals, add code to invalidate the CatalogSnapshot before
waiting for client input. (When the backend is busy, it's unlikely that
the CatalogSnapshot would be the oldest snap for very long, so we don't
worry about forcing early invalidation of it otherwise.)
In passing, remove the CatalogSnapshotStale flag in favor of using
"CatalogSnapshot != NULL" to represent validity, as we do for the other
special snapshots in snapmgr.c. And improve some obsolete comments.
No regression test because I don't know a deterministic way to cause this
failure. But the stress test shown in the original discussion provokes
"cache lookup failed for relation 1255" within a few dozen seconds for me.
Back-patch to 9.4 where MVCC catalog scans were introduced. (Note: it's
quite easy to produce similar failures with the same test case in branches
before 9.4. But MVCC catalog scans were supposed to fix that.)
Discussion: <16447.1478818294@sss.pgh.pa.us>
M src/backend/tcop/postgres.c
M src/backend/utils/time/snapmgr.c
M src/include/utils/snapmgr.h
Fix typo in comment
commit : 7fcaec032f88a29d1f0c0f03a1c35be112992e4c
author : Magnus Hagander <magnus@hagander.net>
date : Mon, 14 Nov 2016 17:31:35 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Mon, 14 Nov 2016 17:31:35 +0100
The function was renamed in 908e23473, but the comment never learned
about it.
M src/backend/utils/adt/jsonfuncs.c
Fix duplication in ALTER MATERIALIZE VIEW synopsis
commit : cd2ec8aaa16e20e07c12d076f5235e3764a963ed
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 14 Nov 2016 11:14:34 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 14 Nov 2016 11:14:34 -0300
Commit 3c4cf080879b should have removed SET TABLESPACE from the synopsis
of ALTER MATERIALIZE VIEW as a possible "action" when it added a
separate line for it in the main command listing, but failed to.
Repair.
Backpatch to 9.4, like the aforementioned commit.
M doc/src/sgml/ref/alter_materialized_view.sgml
Doc: remove obsolete example.
commit : 6f932cac7a20995e07d8c546143c45793a5072a0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 13 Nov 2016 13:12:35 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 13 Nov 2016 13:12:35 -0500
The documentation for ts_headline() recommends using a sub-select to
avoid extra evaluations of ts_headline() in a query with ORDER BY+LIMIT.
Since commit 9118d03a8 this contortionism is unnecessary, so remove the
recommendation. Noted by Oleg Bartunov.
Discussion: <CAF4Au4w6rrH_j1bvVhzpOsRiHCog7sGJ3LSX0tY8ZdwhHT88LQ@mail.gmail.com>
M doc/src/sgml/textsearch.sgml
Doc: fix data types of FuncCallContext's call_cntr and max_calls fields.
commit : cc302f375aed9c8987df6f6951e6b9da19fd4ada
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 11 Nov 2016 12:03:49 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 11 Nov 2016 12:03:49 -0500
Commit 23a27b039 widened these from uint32 to uint64, but I overlooked
that the documentation explicitly showed them as uint32. Per report
from Vicky Vergara.
Report: <20161111135422.8761.36733@wrigleys.postgresql.org>
M doc/src/sgml/xfunc.sgml
Re-allow user_catalog_table option for materialized views.
commit : 05a6e872898acad6a66f9fd0be01e30ae1fb0f75
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 10 Nov 2016 15:00:58 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 10 Nov 2016 15:00:58 -0500
The reloptions stuff allows this option to be set on a matview.
While it's questionable whether that is useful or was really intended,
it does work, and we shouldn't change that in minor releases. Commit
e3e66d8a9 disabled the option since I didn't realize that it was
possible for it to be set on a matview. Tweak the test to re-allow it.
Discussion: <19749.1478711862@sss.pgh.pa.us>
M src/include/utils/rel.h
Fix partial aggregation for the case of a degenerate GROUP BY clause.
commit : 7defc3b97a31537547053946808a83e7234d1b61
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 10 Nov 2016 11:31:56 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 10 Nov 2016 11:31:56 -0500
The plan generated for sorted partial aggregation with "GROUP BY constant"
included a Sort node with no sort keys, which the executor does not like.
Per report from Steve Randall. I'd add a regression test case if I could
think of a compact one, but it doesn't seem worth expending lots of cycles
on.
Report: <CABVd52UAdGXpg_rCk46egpNKYdXOzCjuJ1zG26E2xBe_8bj+Fg@mail.gmail.com>
M src/backend/optimizer/plan/planner.c
Fix typo
commit : c32e05bce74cbb965f8f847d65caa20947b4d2bb
author : Magnus Hagander <magnus@hagander.net>
date : Tue, 8 Nov 2016 18:34:59 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Tue, 8 Nov 2016 18:34:59 +0100
M doc/src/sgml/ref/pg_basebackup.sgml
Change qr/foo$/m to qr/foo\n/m, for Perl 5.8.8.
commit : 91ba77c722928429ebdb042075f7c0bf9d50cf34
author : Noah Misch <noah@leadboat.com>
date : Mon, 7 Nov 2016 20:27:30 -0500
committer: Noah Misch <noah@leadboat.com>
date : Mon, 7 Nov 2016 20:27:30 -0500
In each case, absence of a trailing newline would itself constitute a
PostgreSQL bug. Therefore, this slightly enhances the changed tests.
This works around a bug that last appeared in Perl 5.8.8, fixing
src/test/modules/test_pg_dump when run against that version. Commit
e7293e3271bf618eeb2d4779a15fc516a69fe463 worked around the bug, but the
subsequent addition of test_pg_dump introduced affected code. As that
commit had shown, slight increases in pattern complexity can suppress
the bug. This commit edits qr/foo$/m patterns too complex to encounter
the bug today, for style consistency and robustness against unrelated
pattern changes. Back-patch to 9.6, where test_pg_dump was introduced.
As of this writing, a fresh MSYS installation includes an affected Perl
5.8.8. The Perl 5.8.8 in Red Hat Enterprise Linux 5.11 carries a patch
that renders it unaffected, but the Perl 5.8.5 of Red Hat Enterprise
Linux 4.4 is affected.
M src/bin/pg_basebackup/t/010_pg_basebackup.pl
M src/test/modules/test_pg_dump/t/001_base.pl
M src/test/perl/README
M src/tools/msvc/Project.pm
Band-aid fix for incorrect use of view options as StdRdOptions.
commit : 5ee3a7453a428890ed4c0a1061c367e510b8253b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 7 Nov 2016 12:08:19 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 7 Nov 2016 12:08:19 -0500
We really ought to make StdRdOptions and the other decoded forms of
reloptions self-identifying, but for the moment, assume that only plain
relations could possibly be user_catalog_tables. Fixes problem with bogus
"ON CONFLICT is not supported on table ... used as a catalog table" error
when target is a view with cascade option.
Discussion: <26681.1477940227@sss.pgh.pa.us>
M src/include/utils/rel.h
M src/test/regress/expected/insert_conflict.out
M src/test/regress/sql/insert_conflict.sql
pg_rewing pg_upgrade: Fix translation markers
commit : 674f7015caa044bed73a5883f1d4b088ac0adf22
author : Peter Eisentraut <peter_e@gmx.net>
date : Mon, 7 Nov 2016 12:00:00 -0500
committer: Peter Eisentraut <peter_e@gmx.net>
date : Mon, 7 Nov 2016 12:00:00 -0500
In pg_log_v(), we need to translate the fmt before processing, not the
formatted message afterwards.
M src/bin/pg_rewind/logging.c
M src/bin/pg_upgrade/util.c
Fix handling of symlinked pg_stat_tmp and pg_replslot
commit : b6a323a8c9b8f75a974e44cc6bb91f0d08e19e7f
author : Magnus Hagander <magnus@hagander.net>
date : Mon, 7 Nov 2016 14:47:30 +0100
committer: Magnus Hagander <magnus@hagander.net>
date : Mon, 7 Nov 2016 14:47:30 +0100
This was already fixed in HEAD as part of 6ad8ac60 but was not
backpatched.
Also change the way pg_xlog is handled to be the same as the other
directories.
Patch from me with pg_xlog addition from Michael Paquier, test updates
from David Steele.
M src/backend/replication/basebackup.c
M src/bin/pg_basebackup/t/010_pg_basebackup.pl
Rationalize and document pltcl's handling of magic ".tupno" array element.
commit : 3af8467e9a5950f3ee908607867a008e0442f108
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 6 Nov 2016 14:43:13 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 6 Nov 2016 14:43:13 -0500
For a very long time, pltcl's spi_exec and spi_execp commands have had
a behavior of storing the current row number as an element of output
arrays, but this was never documented. Fix that.
For an equally long time, pltcl_trigger_handler had a behavior of silently
ignoring ".tupno" as an output column name, evidently so that the result
of spi_exec could be used directly as a trigger result tuple. Not sure
how useful that really is, but in any case it's bad that it would break
attempts to use ".tupno" as an actual column name. We can fix it by not
checking for ".tupno" until after we check for a column name match. This
comports with the effective behavior of spi_exec[p] that ".tupno" is only
magic when you don't have an actual column named that.
In passing, wordsmith the description of returning modified tuples from
a pltcl trigger.
Noted while working on Jim Nasby's patch to support composite results
from pltcl. The inability to return trigger tuples using ".tupno" as
a column name is a bug, so back-patch to all supported branches.
M doc/src/sgml/pltcl.sgml
M src/pl/tcl/pltcl.c
Need to do SPI_push/SPI_pop around expression evaluation in plpgsql.
commit : a5b153ff51945034467adbfef1aa0e8f8c1e3267
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 6 Nov 2016 12:09:36 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 6 Nov 2016 12:09:36 -0500
We must do this in case the expression evaluation results in calling
another plpgsql function (or, really, anything using SPI). I missed
the need for this when I converted exec_cast_value() from doing a
simple InputFunctionCall() to doing ExecEvalExpr() in commit 1345cc67b.
There is a SPI_push_conditional in InputFunctionCall(), so that there
was no bug before that.
Per bug #14414 from Marcos Castedo. Add a regression test based on his
example, which was that a plpgsql function in a domain check constraint
didn't work when assigning to a domain-type variable within plpgsql.
Report: <20161106010947.1387.66380@wrigleys.postgresql.org>
M src/pl/plpgsql/src/pl_exec.c
M src/test/regress/expected/plpgsql.out
M src/test/regress/sql/plpgsql.sql
More zic cleanup.
commit : 20559a854662e6beb4864fc8125cb6401d8b07fa
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 6 Nov 2016 10:45:58 -0500
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 6 Nov 2016 10:45:58 -0500
The workaround the IANA guys chose to get rid of the clang warning
we'd silenced in commit 23ed2ba81 turns out not to satisfy Coverity.
Go back to the previous solution, ie, remove the useless comparison
to SIZE_MAX. (In principle, there could be machines out there where
it's not useless because ptrdiff_t is wider than size_t. But the whole
thing is pretty academic anyway, as we could never approach this limit
for any sane estimate of the amount of data that zic will ever be asked
to work with.)
Also, s/lineno/lineno_t/g, because if we accept their decision to start
using "lineno" as a typedef, it is going to have very unpleasant
consequences in our next pgindent run. Noted that while fooling with
pltcl yesterday.
M src/timezone/zic.c
Remove duplicate macro definition.
commit : 5c24c61273889cc773314cdb3f9891d1faf612fd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 5 Nov 2016 11:51:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 5 Nov 2016 11:51:46 -0400
Seems to be a copy-and-pasteo. Odd that we heard no reports of
compiler warnings about it.
Thomas Munro
M src/include/access/xact.h
Back-patch portability fixes for contrib/pageinspect/ginfuncs.c.
commit : 4774f61830290eb4c14bf2770c3167b3dd786120
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 4 Nov 2016 12:37:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 4 Nov 2016 12:37:29 -0400
Back-patch commits 84ad68d64 and 367b99bbb.
M contrib/pageinspect/ginfuncs.c
Sync our copy of the timezone library with IANA tzcode master.
commit : 7afafe8af36cd0c16f152dc9c674c26054972edd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 4 Nov 2016 10:44:16 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 4 Nov 2016 10:44:16 -0400
This patch absorbs some unreleased fixes for symlink manipulation bugs
introduced in tzcode 2016g. Ordinarily I'd wait around for a released
version, but in this case it seems like we could do with extra testing,
in particular checking whether it works in EDB's VMware build environment.
This corresponds to commit aec59156abbf8472ba201b6c7ca2592f9c10e077 in
https://github.com/eggert/tz.
Per a report from Sandeep Thakkar, building in an environment where hard
links are not supported in the timezone data installation directory failed,
because upstream code refactoring had broken the case of symlinking from an
existing symlink. Further experimentation also showed that the symlinks
were sometimes made incorrectly, with too many or too few "../"'s in the
symlink contents.
Back-patch of commit 1f87181e12beb067d21b79493393edcff14c190b.
Report: <CANFyU94_p6mqRQc2i26PFp5QAOQGB++AjGX=FO8LDpXw0GSTjw@mail.gmail.com>
Discussion: http://mm.icann.org/pipermail/tz/2016-November/024431.html
M src/timezone/zic.c
Don't make FK-based selectivity estimates in inheritance situations.
commit : 23c6c437f98c996092c0adfad6152d9cc699c8b0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Nov 2016 15:50:15 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Nov 2016 15:50:15 -0400
The foreign-key-aware logic for estimation of join sizes (added in commit
100340e2d) blindly tried to apply the concept to rels that are actually
parents of inheritance trees. This is just plain wrong so far as the
referenced relation is concerned, since the inheritance scan may well
produce lots of rows that are not participating in the constraint. It's
wrong for the referencing relation too, for the same reason; although on
that end we could conceivably detect whether all members of the inheritance
tree have equivalent FK constraints pointing to the same referenced rel,
and then proceed more or less as we do now. But pending somebody writing
code to do that, we must disable this, because it's producing completely
silly estimates when there's an FK linking the heads of inheritance trees.
Per bug #14404 from Clinton Adams. Back-patch to 9.6 where the new
estimation logic came in.
Report: <20161028200412.15987.96482@wrigleys.postgresql.org>
M src/backend/optimizer/util/plancat.c
Don't convert Consts into Vars during setrefs.c processing.
commit : f4d865f22d0f6fab1525786a8b98051d29214f30
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Nov 2016 14:32:13 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Nov 2016 14:32:13 -0400
While converting expressions in an upper-level plan node so that they
reference Vars and expressions provided by the input plan node(s),
don't convert plain Const items, even if there happens to be a matching
Const in the input. It's silly to do so because a Var is more expensive to
execute than a Const. Moreover, converting can fool ExecCheckPlanOutput's
check that an insert or update query inserts nulls into dropped columns,
leading to "query provides a value for a dropped column" errors during
INSERT or UPDATE on a table with a dropped column. We could solve this
by making that check more complicated, but I don't see the point; this fix
should save a marginal number of cycles, and it also makes for less messy
EXPLAIN output, as shown by the ensuing regression test result changes.
Per report from Pavel Hanák. I have not incorporated a test case based
on that example, as there doesn't seem to be a simple way of checking
this in isolation without making a bunch of assumptions about other
planner and SQL-function behavior.
Back-patch to 9.6. This setrefs.c behavior exists much further back,
but there is not currently reason to think that it causes problems
before 9.6.
Discussion: <83shraampf.fsf@is-it.eu>
M src/backend/optimizer/plan/setrefs.c
M src/test/regress/expected/inherit.out
Fix portability bug in gin_page_opaque_info().
commit : 2a8783e440b5ede18e16b48c37be65ce7caedd52
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Nov 2016 00:09:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 2 Nov 2016 00:09:28 -0400
Somebody apparently thought that "if Int32GetDatum is good,
Int64GetDatum must be better". Per buildfarm failures now
that Peter has added some regression tests here.
M contrib/pageinspect/ginfuncs.c
Fix typo in sources.sgml.
commit : b0034e71989f03b78e8ebcb02e62acffc6fc0351
author : Tatsuo Ishii <ishii@postgresql.org>
date : Mon, 31 Oct 2016 07:30:46 +0900
committer: Tatsuo Ishii <ishii@postgresql.org>
date : Mon, 31 Oct 2016 07:30:46 +0900
Per Shinichi Matsuda.
M doc/src/sgml/sources.sgml
Fix nasty performance problem in tsquery_rewrite().
commit : 464326e83b4cb7ef7211eb00bdb4acd4ea2d42cf
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 30 Oct 2016 17:35:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 30 Oct 2016 17:35:42 -0400
tsquery_rewrite() tries to find matches to subsets of AND/OR conditions;
for example, in the query 'a | b | c' the substitution subquery 'a | c'
should match and lead to replacement of the first and third items.
That's fine, but the matching algorithm apparently takes about O(2^N)
for an N-clause query (I say "apparently" because the code is also both
unintelligible and uncommented). We could probably do better than that
even without any extra assumptions --- but actually, we know that the
subclauses are sorted, indeed are depending on that elsewhere in this very
same function. So we can just scan the two lists a single time to detect
matches, as though we were doing a merge join.
Also do a re-flattening call (QTNTernary()) in tsquery_rewrite_query, just
to make sure that the tree fits the expectations of the next search cycle.
I didn't try to devise a test case for this, but I'm pretty sure that the
oversight could have led to failure to match in some cases where a match
would be expected.
Improve comments, and also stick a CHECK_FOR_INTERRUPTS into
dofindsubquery, just in case it's still too slow for somebody.
Per report from Andreas Seltenreich. Back-patch to all supported branches.
Discussion: <8760oasf2y.fsf@credativ.de>
M src/backend/utils/adt/tsquery_rewrite.c
Fix bogus tree-flattening logic in QTNTernary().
commit : 2a2b439cc14288c539b4b875df275766845c4c99
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 30 Oct 2016 15:24:40 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 30 Oct 2016 15:24:40 -0400
QTNTernary() contains logic to flatten, eg, '(a & b) & c' into 'a & b & c',
which is all well and good, but it tries to do that to NOT nodes as well,
so that '!!a' gets changed to '!a'. Explicitly restrict the conversion to
be done only on AND and OR nodes, and add a test case illustrating the bug.
In passing, provide some comments for the sadly naked functions in
tsquery_util.c, and simplify some baroque logic in QTNFree(), which
I think may have been leaking some items it intended to free.
Noted while investigating a complaint from Andreas Seltenreich.
Back-patch to all supported versions.
M src/backend/utils/adt/tsquery_util.c
M src/test/regress/expected/tsearch.out
M src/test/regress/sql/tsearch.sql
Improve speed of aggregates that use array_append as transition function.
commit : 48a6592daedaa79ab786d3446d1685090093a169
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 30 Oct 2016 12:27:41 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 30 Oct 2016 12:27:41 -0400
In the previous coding, if an aggregate's transition function returned an
expanded array, nodeAgg.c and nodeWindowAgg.c would always copy it and thus
force it into the flat representation. This led to ping-ponging between
flat and expanded formats, which costs a lot. For an aggregate using
array_append as transition function, I measured about a 15X slowdown
compared to the pre-9.5 code, when working on simple int[] arrays.
Of course, the old code was already O(N^2) in this usage due to copying
flat arrays all the time, but it wasn't quite this inefficient.
To fix, teach nodeAgg.c and nodeWindowAgg.c to allow expanded transition
values without copying, so long as the transition function takes care to
return the transition value already properly parented under the aggcontext.
That puts a bit of extra responsibility on the transition function, but
doing it this way allows us to not need any extra logic in the fast path
of advance_transition_function (ie, with a pass-by-value transition value,
or with a modified-in-place pass-by-reference value). We already know
that that's a hot spot so I'm loath to add any cycles at all there. Also,
while only array_append currently knows how to follow this convention,
this solution allows other transition functions to opt-in without needing
to have a whitelist in the core aggregation code.
(The reason we would need a whitelist is that currently, if you pass a
R/W expanded-object pointer to an arbitrary function, it's allowed to do
anything with it including deleting it; that breaks the core agg code's
assumption that it should free discarded values. Returning a value under
aggcontext is the transition function's signal that it knows it is an
aggregate transition function and will play nice. Possibly the API rules
for expanded objects should be refined, but that would not be a
back-patchable change.)
With this fix, an aggregate using array_append is no longer O(N^2), so it's
much faster than pre-9.5 code rather than much slower. It's still a bit
slower than the bespoke infrastructure for array_agg, but the differential
seems to be only about 10%-20% rather than orders of magnitude.
Discussion: <6315.1477677885@sss.pgh.pa.us>
M doc/src/sgml/xaggr.sgml
M src/backend/executor/nodeAgg.c
M src/backend/executor/nodeWindowAgg.c
M src/backend/optimizer/util/clauses.c
M src/backend/utils/adt/array_userfuncs.c
If the stats collector dies during Hot Standby, restart it.
commit : 4a43a6244d93dd0e16a898ff18d8641512b6006c
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 27 Oct 2016 14:27:40 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 27 Oct 2016 14:27:40 -0400
This bug exists as far back as 9.0, when Hot Standby was introduced,
so back-patch to all supported branches.
Report and patch by Takayuki Tsunakawa, reviewed by Michael Paquier
and Kuntal Ghosh.
M src/backend/postmaster/postmaster.c
Fix possible pg_basebackup failure on standby with "include WAL".
commit : 05e2293f4c70cdda00357322f62e3ccd8b1043db
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 27 Oct 2016 11:19:51 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 27 Oct 2016 11:19:51 -0400
If a restartpoint flushed no dirty buffers, it could fail to update
the minimum recovery point, leading to a minimum recovery point prior
to the starting REDO location. perform_base_backup() would interpret
that as meaning that no WAL files at all needed to be included in the
backup, failing an internal sanity check. To fix, have restartpoints
always update the minimum recovery point to just after the checkpoint
record itself, so that the file (or files) containing the checkpoint
record will always be included in the backup.
Code by Amit Kapila, per a design suggestion by me, with some
additional work on the code comment by me. Test case by Michael
Paquier. Report by Kyotaro Horiguchi.
M src/backend/access/transam/xlog.c
M src/test/recovery/t/001_stream_rep.pl
Fix incorrect trigger-property updating in ALTER CONSTRAINT.
commit : 445035a6ed148fd79ea82f484284219673cd138d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 26 Oct 2016 17:05:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 26 Oct 2016 17:05:06 -0400
The code to change the deferrability properties of a foreign-key constraint
updated all the associated triggers to match; but a moment's examination of
the code that creates those triggers in the first place shows that only
some of them should track the constraint's deferrability properties. This
leads to odd failures in subsequent exercise of the foreign key, as the
triggers are fired at the wrong times. Fix that, and add a regression test
comparing the trigger properties produced by ALTER CONSTRAINT with those
you get by creating the constraint as-intended to begin with.
Per report from James Parks. Back-patch to 9.4 where this ALTER
functionality was introduced.
Report: <CAJ3Xv+jzJ8iNNUcp4RKW8b6Qp1xVAxHwSXVpjBNygjKxcVuE9w@mail.gmail.com>
M src/backend/commands/tablecmds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Fix not-HAVE_SYMLINK code in zic.c.
commit : 99f13d1617c9b2bcf647f4eff2504394dbf3fb70
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 26 Oct 2016 13:40:41 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 26 Oct 2016 13:40:41 -0400
I broke this in commit f3094920a. Apparently it's dead code anyway,
at least as far as our buildfarm is concerned (and the upstream IANA
code doesn't worry at all about symlink() not being present).
But as long as the rest of our code is willing to guard against not
having symlink(), this should too. Noted while investigating a
tangentially-related complaint from Sandeep Thakkar.
Back-patch to keep branches in sync.
M src/timezone/zic.c
Doc: improve documentation about inheritance.
commit : fab220b415700ac29637465e96f6745ec6e1cdb6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 26 Oct 2016 11:46:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 26 Oct 2016 11:46:25 -0400
Clarify documentation about inheritance of check constraints, in
particular mentioning the NO INHERIT option, which didn't exist when
this text was written.
Document that in an inherited query, the applicable row security policies
are those of the explicitly-named table, not its children. This is the
intended behavior (per off-list discussion with Stephen Frost), and there
are regression tests for it, but it wasn't documented anywhere user-facing
as far as I could find.
Do a bit of wordsmithing on the description of inherited access-privilege
checks.
Back-patch to 9.5 where RLS was added.
M doc/src/sgml/ddl.sgml
Fix typos in comments.
commit : e9c0335c3306f7737c7b3fc0cf0c36ff19397e19
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 26 Oct 2016 11:12:31 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 26 Oct 2016 11:12:31 +0300
Vinayak Pokale
M src/backend/postmaster/pgstat.c
M src/backend/replication/logical/reorderbuffer.c
M src/include/pgstat.h
Fix typo in comment.
commit : e3c5e48bb82975cfca4c90a30fd8e2452840909d
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 26 Oct 2016 11:10:13 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 26 Oct 2016 11:10:13 +0300
Daniel Gustafsson
M contrib/pageinspect/heapfuncs.c