Stamp 12.0.
commit : ad1f2885b8c82e0c2d56d7974f012cbecce17a17
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 30 Sep 2019 16:03:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 30 Sep 2019 16:03:42 -0400
M configure
M configure.in
M src/include/pg_config.h.win32
Suppress another CR in program output
commit : b60f9afcf4bfe6b1ff73b49b9bab20dde356c7f4
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 30 Sep 2019 15:48:54 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 30 Sep 2019 15:48:54 -0400
This one was exposed by a12c75a10.
Backpatch to release 11 where check_pg_config was introduced.
M src/test/perl/TestLib.pm
Doc: improve PREPARE documentation, cross-referencing to plan_cache_mode.
commit : ca0b3828504a51247607913e16f45c635ec168b6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 30 Sep 2019 14:31:12 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 30 Sep 2019 14:31:12 -0400
The behavior described in the PREPARE man page applies only for the
default plan_cache_mode setting, so explain that properly. Rewrite
some of the text while I'm here. Per suggestion from Bruce.
Discussion: https://postgr.es/m/20190930155505.GA21095@momjian.us
M doc/src/sgml/config.sgml
M doc/src/sgml/ref/prepare.sgml
docs: adjust multi-column most-common-value statistics
commit : 737f226842748cf946cad3bd30aadfd0c03ad16f
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 30 Sep 2019 13:44:22 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 30 Sep 2019 13:44:22 -0400
This commit adds a mention that the order of columns specified during
multi-column most-common-value statistics is insignificant, and tries to
simplify examples.
Discussion: https://postgr.es/m/20190828162238.GA8360@momjian.us
Backpatch-through: 12
M doc/src/sgml/perform.sgml
M doc/src/sgml/ref/create_statistics.sgml
Doc: update v12 release notes.
commit : 9d42df74a3ad0379fe90e56c92eecac6957876f3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 30 Sep 2019 12:03:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 30 Sep 2019 12:03:28 -0400
Set the release date, make a few adjustments for recent commits.
M doc/src/sgml/release-12.sgml
Make crash recovery ignore recovery target settings.
commit : 4af2ac3deeca24d3b8cb1abeb49bd62a7d013fa3
author : Fujii Masao <fujii@postgresql.org>
date : Mon, 30 Sep 2019 10:18:15 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Mon, 30 Sep 2019 10:18:15 +0900
In v11 or before, recovery target settings could not take effect in
crash recovery because they are specified in recovery.conf and
crash recovery always starts without recovery.conf. But commit
2dedf4d9a8 integrated recovery.conf into postgresql.conf and
which unexpectedly allowed recovery target settings to take effect
even in crash recovery. This is definitely not good behavior.
To fix the issue, this commit makes crash recovery always ignore
recovery target settings.
Back-patch to v12.
Author: Peter Eisentraut
Reviewed-by: Fujii Masao
Discussion: https://postgr.es/m/e445616d-023e-a268-8aa1-67b8b335340c@pgmasters.net
M src/backend/access/transam/xlog.c
jit: Re-allow JIT compilation of execGrouping.c hashtable comparisons.
commit : 2ce9bca36458a1f1907c82eb2e9bd642cb1fca26
author : Andres Freund <andres@anarazel.de>
date : Sun, 29 Sep 2019 16:27:18 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sun, 29 Sep 2019 16:27:18 -0700
In the course of 5567d12ce03, 356687bd8 and 317ffdfeaac, I changed
BuildTupleHashTable[Ext]'s call to ExecBuildGroupingEqual to not pass
in the parent node, but NULL. Which in turn prevents the tuple
equality comparator from being JIT compiled. While that fixes
bug #15486, it is not actually necessary after all of the above commits,
as we don't re-build the comparator when using the new
BuildTupleHashTableExt() interface (as the content of the hashtable
are reset, but the TupleHashTable itself is not).
Therefore re-allow jit compilation for callers that use
BuildTupleHashTableExt with a separate context for "metadata" and
content.
As in the previous commit, there's ongoing work to make this easier to
test to prevent such regressions in the future, but that
infrastructure is not going to be backpatchable.
The performance impact of not JIT compiling hashtable equality
comparators can be substantial e.g. for aggregation queries that
aggregate a lot of input rows to few output rows (when there are a lot
of output groups, there will be fewer comparisons).
Author: Andres Freund
Discussion: https://postgr.es/m/20190927072053.njf6prdl3vb7y7qb@alap3.anarazel.de
Backpatch: 11, just as 5567d12ce03
M src/backend/executor/execGrouping.c
Fix determination when slot types for upper executor nodes are fixed.
commit : 6cf74f1bbd6545321d9e2929c7618550863f72d1
author : Andres Freund <andres@anarazel.de>
date : Sun, 29 Sep 2019 15:24:54 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sun, 29 Sep 2019 15:24:54 -0700
For many queries the fact that the tuple descriptor from the lower
node was not taken into account when determining whether the type of a
slot is fixed, lead to tuple deforming for such upper nodes not to be
JIT accelerated.
I broke this in 675af5c01e297.
There is ongoing work to enable writing regression tests for related
behavior (including a patch that would have detected this
regression), by optionally showing such details in EXPLAIN. But as it
seems unlikely that that will be suitable for stable branches, just
merge the fix for now.
While it's fairly close to the 12 release window, the fact that 11
continues to perform JITed tuple deforming in these cases, that
there's still cases where we do so in 12, and the fact that the
performance regression can be sizable, weigh in favor of fixing it
now.
Author: Andres Freund
Discussion: https://postgr.es/m/20190927072053.njf6prdl3vb7y7qb@alap3.anarazel.de
Backpatch: 12-, where 675af5c01e297 was merged.
M src/backend/executor/execExpr.c
Translation updates
commit : 3c70de2e12b9ef10925a57a350dffc01b95e067e
author : Peter Eisentraut <peter@eisentraut.org>
date : Sun, 29 Sep 2019 23:46:15 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sun, 29 Sep 2019 23:46:15 +0200
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 1d66650d203c89e3c69a18be3b4361f5a5393fcf
M src/backend/nls.mk
M src/backend/po/de.po
D src/backend/po/id.po
D src/backend/po/pt_BR.po
M src/backend/po/sv.po
M src/bin/initdb/nls.mk
M src/bin/initdb/po/cs.po
M src/bin/initdb/po/fr.po
D src/bin/initdb/po/he.po
D src/bin/initdb/po/it.po
D src/bin/initdb/po/ko.po
D src/bin/initdb/po/pl.po
D src/bin/initdb/po/pt_BR.po
D src/bin/initdb/po/vi.po
M src/bin/pg_archivecleanup/nls.mk
A src/bin/pg_archivecleanup/po/cs.po
D src/bin/pg_archivecleanup/po/ko.po
D src/bin/pg_archivecleanup/po/pl.po
D src/bin/pg_archivecleanup/po/vi.po
M src/bin/pg_basebackup/nls.mk
A src/bin/pg_basebackup/po/cs.po
D src/bin/pg_basebackup/po/fr.po
D src/bin/pg_basebackup/po/he.po
D src/bin/pg_basebackup/po/it.po
D src/bin/pg_basebackup/po/ko.po
D src/bin/pg_basebackup/po/pl.po
D src/bin/pg_basebackup/po/pt_BR.po
D src/bin/pg_basebackup/po/vi.po
M src/bin/pg_checksums/nls.mk
A src/bin/pg_checksums/po/cs.po
M src/bin/pg_config/nls.mk
M src/bin/pg_config/po/cs.po
D src/bin/pg_config/po/nb.po
D src/bin/pg_config/po/ta.po
M src/bin/pg_controldata/nls.mk
M src/bin/pg_controldata/po/cs.po
D src/bin/pg_controldata/po/pt_BR.po
M src/bin/pg_ctl/nls.mk
M src/bin/pg_ctl/po/cs.po
D src/bin/pg_ctl/po/pt_BR.po
M src/bin/pg_dump/nls.mk
M src/bin/pg_dump/po/cs.po
D src/bin/pg_dump/po/fr.po
D src/bin/pg_dump/po/he.po
D src/bin/pg_dump/po/it.po
D src/bin/pg_dump/po/ko.po
D src/bin/pg_dump/po/pl.po
D src/bin/pg_dump/po/pt_BR.po
M src/bin/pg_resetwal/nls.mk
M src/bin/pg_resetwal/po/cs.po
D src/bin/pg_resetwal/po/fr.po
D src/bin/pg_resetwal/po/it.po
D src/bin/pg_resetwal/po/ko.po
D src/bin/pg_resetwal/po/pl.po
D src/bin/pg_resetwal/po/pt_BR.po
M src/bin/pg_rewind/nls.mk
A src/bin/pg_rewind/po/cs.po
D src/bin/pg_rewind/po/fr.po
D src/bin/pg_rewind/po/it.po
D src/bin/pg_rewind/po/ko.po
D src/bin/pg_rewind/po/pl.po
D src/bin/pg_rewind/po/pt_BR.po
M src/bin/pg_upgrade/po/cs.po
M src/bin/pg_waldump/nls.mk
A src/bin/pg_waldump/po/cs.po
D src/bin/pg_waldump/po/ko.po
D src/bin/pg_waldump/po/vi.po
M src/bin/psql/nls.mk
M src/bin/psql/po/cs.po
M src/bin/psql/po/fr.po
D src/bin/psql/po/he.po
D src/bin/psql/po/ko.po
D src/bin/psql/po/pl.po
D src/bin/psql/po/pt_BR.po
D src/bin/psql/po/zh_TW.po
M src/bin/scripts/nls.mk
M src/bin/scripts/po/cs.po
D src/bin/scripts/po/fr.po
D src/bin/scripts/po/he.po
D src/bin/scripts/po/it.po
D src/bin/scripts/po/ko.po
D src/bin/scripts/po/pl.po
D src/bin/scripts/po/pt_BR.po
M src/interfaces/ecpg/ecpglib/po/fr.po
M src/interfaces/ecpg/preproc/po/cs.po
M src/interfaces/ecpg/preproc/po/fr.po
M src/interfaces/libpq/nls.mk
M src/interfaces/libpq/po/cs.po
D src/interfaces/libpq/po/pl.po
D src/interfaces/libpq/po/pt_BR.po
M src/interfaces/libpq/po/sv.po
D src/interfaces/libpq/po/zh_TW.po
M src/pl/plperl/nls.mk
M src/pl/plperl/po/cs.po
D src/pl/plperl/po/zh_TW.po
M src/pl/plpgsql/src/nls.mk
M src/pl/plpgsql/src/po/cs.po
D src/pl/plpgsql/src/po/ro.po
D src/pl/plpgsql/src/po/zh_TW.po
M src/pl/plpython/po/cs.po
M src/pl/tcl/nls.mk
M src/pl/tcl/po/cs.po
D src/pl/tcl/po/pt_BR.po
D src/pl/tcl/po/ro.po
D src/pl/tcl/po/zh_TW.po
Update list of acknowledgments in release notes
commit : f0eadaa717eae75392d03479aea282bc752df276
author : Peter Eisentraut <peter@eisentraut.org>
date : Sun, 29 Sep 2019 23:38:51 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sun, 29 Sep 2019 23:38:51 +0200
M doc/src/sgml/release-12.sgml
Allow SSL TAP tests to run on Windows
commit : 63d3e1142a0554c33818741d44926fc036a0499b
author : Andrew Dunstan <andrew@dunslane.net>
date : Sun, 29 Sep 2019 17:32:46 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Sun, 29 Sep 2019 17:32:46 -0400
Windows does not enforce key file permissions checks in libpq, and psql
can produce CRLF line endings on Windows.
Backpatch to Release 12 (CRLF) and Release 11 (permissions check)
M src/test/ssl/t/001_ssltests.pl
doc: Clarify release notes item
commit : bba1baecb7b07dff33e4c5d32253db5f4c1a0507
author : Peter Eisentraut <peter@eisentraut.org>
date : Sun, 29 Sep 2019 23:29:45 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sun, 29 Sep 2019 23:29:45 +0200
Reported-by: Justin Pryzby <pryzby@telsasoft.com>
M doc/src/sgml/release-12.sgml
doc: Further clarify how recovery target parameters are applied
commit : a7e5ae53cbe7bd88102b38d5f6e15f5adc94e15c
author : Peter Eisentraut <peter@eisentraut.org>
date : Sun, 29 Sep 2019 23:07:22 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sun, 29 Sep 2019 23:07:22 +0200
Recovery target parameters are all applied even in standby mode. The
previous documentation mostly wished they were not but this was never
the case.
Discussion: https://www.postgresql.org/message-id/flat/e445616d-023e-a268-8aa1-67b8b335340c%40pgmasters.net
M doc/src/sgml/config.sgml
doc: Release notes refinements
commit : 3e3e32a1c160ec4e2342068515dfaf1dd04c6078
author : Peter Eisentraut <peter@eisentraut.org>
date : Sun, 29 Sep 2019 09:50:36 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sun, 29 Sep 2019 09:50:36 +0200
In particular, make some more precise links for some major items.
M doc/src/sgml/ref/alter_table.sgml
M doc/src/sgml/release-12.sgml
Fix compilation with older OpenSSL versions
commit : a430c7b4afe8278223541d3efee2281ee9135c1d
author : Peter Eisentraut <peter@eisentraut.org>
date : Sat, 28 Sep 2019 15:54:02 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sat, 28 Sep 2019 15:54:02 +0200
Some older OpenSSL versions (0.9.8 branch) define TLS*_VERSION macros
but not the corresponding SSL_OP_NO_* macro, which causes the code for
handling ssl_min_protocol_version/ssl_max_protocol_version to fail to
compile. To fix, add more #ifdefs and error handling.
Reported-by: Victor Wagner <vitus@wagner.pp.ru>
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://www.postgresql.org/message-id/flat/20190924101859.09383b4f%40fafnir.local.vm
M src/backend/libpq/be-secure-openssl.c
Improve stability of partition_prune regression test.
commit : 9de7ea6aca5a394dbddac4b13b475b313e352b3f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 28 Sep 2019 13:33:34 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 28 Sep 2019 13:33:34 -0400
This test already knew that, to get stable test output, it had to hide
"loops" counts in EXPLAIN ANALYZE results. But that's not nearly enough:
if we get a smaller number of workers than we planned for, then the
"Workers Launched" number will change, and so will all the rows and loops
counts up to the Gather node. This has resulted in repeated failures in
the buildfarm, so adjust the test to filter out all these counts.
(Really, we wouldn't bother with EXPLAIN ANALYZE at all here, except
that currently the only way to verify that executor-time pruning has
happened is to look for '(never executed)' annotations. Those are
stable and needn't be filtered out.)
Back-patch to v11 where the test was introduced.
Discussion: https://postgr.es/m/11952.1569536725@sss.pgh.pa.us
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql
ANALYZE a_star and its children to avoid plan instability in tests.
commit : e40f3c7472036f5a06897a11ac79fd26ec2ccf7d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 27 Sep 2019 11:28:25 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 27 Sep 2019 11:28:25 -0400
We've noted certain EXPLAIN queries on these tables occasionally showing
unexpected plan choices. This seems to happen because VACUUM sometimes
fails to update relpages/reltuples for one of these single-page tables,
due to bgwriter or checkpointer holding a pin on the lone page at just
the wrong time. To ensure those values get set, insert explicit ANALYZE
operations on these tables after we finish populating them. This
doesn't seem to affect any other test cases, so it's a usable fix.
Back-patch to v12. In principle the issue exists further back, but
we have not seen it before v12, so I won't risk back-patching further.
Discussion: https://postgr.es/m/24480.1569518042@sss.pgh.pa.us
M src/test/regress/expected/create_misc.out
M src/test/regress/sql/create_misc.sql
Doc: clean up markup for jsonb_set and related functions.
commit : b34bc87030655a677b0a4d6317bfe3a6a7d10546
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 27 Sep 2019 11:01:36 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 27 Sep 2019 11:01:36 -0400
The markup for optional parameters was neither correct nor consistent.
In passing, fix a spelling mistake.
Per report from Alex Macy. Some of these mistakes are old, so
back-patch as appropriate.
Discussion: https://postgr.es/m/156953522258.1204.12736099368284950578@wrigleys.postgresql.org
M doc/src/sgml/func.sgml
doc: Add timeline as valid recovery target in standby.signal documentation
commit : a37980d4282436b4019a8e427b02919b04cb625a
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 27 Sep 2019 16:21:47 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 27 Sep 2019 16:21:47 +0200
The documentation states that no target settings will be used when
standby.signal is present, but this is not quite the case since
recovery_target_timeline is a valid recovery target for a standby.
Update the documentation with this exception.
Author: David Steele <david@pgmasters.net>
Discussion: https://www.postgresql.org/message-id/flat/e445616d-023e-a268-8aa1-67b8b335340c%40pgmasters.net
M doc/src/sgml/config.sgml
Add tab completion for EXPLAIN (SETTINGS) in psql
commit : 268c4e9d4d88f5b4baca88ef31e914a1ac1fb7e9
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 27 Sep 2019 12:53:57 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 27 Sep 2019 12:53:57 +0900
Author: Justin Pryzby
Reviewed-by: Tatsuro Yamada
Discussion: https://postgr.es/m/20190927022051.GC24334@telsasoft.com
Backpatch-through: 12
M src/bin/psql/tab-complete.c
Fix oversight in commit 4429f6a9e3e12bb4af6e3677fbc78cd80f160252.
commit : fb341a7db9ba03f365bd02dc47123fbad6cc3761
author : Amit Kapila <akapila@postgresql.org>
date : Wed, 18 Sep 2019 09:14:26 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Wed, 18 Sep 2019 09:14:26 +0530
The test name and the following test cases suggest the index created
should be hash index, but it forgot to add 'using hash' in the test case.
This in itself won't improve code coverage as there were some other tests
which were covering the corresponding code. However, it is better if the
added tests serve their actual purpose.
Reported-by: Paul A Jungwirth
Author: Paul A Jungwirth
Reviewed-by: Mahendra Singh
Backpatch-through: 9.4
Discussion: https://postgr.es/m/CA+renyV=Us-5XfMC25bNp-uWSj39XgHHmGE9Rh2cQKMegSj52g@mail.gmail.com
M src/test/regress/expected/rangetypes.out
M src/test/regress/sql/rangetypes.sql
doc: Fix whitespace in markup
commit : d10475a0433291bfd136df6edb06497af0f52cb8
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 26 Sep 2019 21:29:14 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 26 Sep 2019 21:29:14 +0200
M doc/src/sgml/func.sgml
doc: Format example JSON data better
commit : 79504cfe1b23cd22c78dd5786f81f40905c5cce0
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 26 Sep 2019 21:27:34 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 26 Sep 2019 21:27:34 +0200
M doc/src/sgml/func.sgml
doc: Update a confusing sentence about SQL/JSON
commit : baca53d3dca701e6a8b04a1b2dd0ed603289fbf0
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 26 Sep 2019 16:35:10 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 26 Sep 2019 16:35:10 +0200
Author: Liudmila Mantrova <l.mantrova@postgrespro.ru>
Reported-by: Jeff Janes <jeff.janes@gmail.com>
Discussion: https://www.postgresql.org/message-id/flat/CAMkU%3D1wP-SO4KpiLxHJuPezTJCmK%3DJqefLXrr3eXFO7Qku%2BtMg%40mail.gmail.com
M doc/src/sgml/json.sgml
doc: Update note about source code formatting
commit : b4d615aaa1ecedcf1e2ca415cd2893d1f18aeeca
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 26 Sep 2019 10:51:39 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 26 Sep 2019 10:51:39 +0200
Update the note about why not to use // comments, even though it's now
technically supported.
The note about variable declarations was dropped here because it's
addressed more properly later in the chapter.
Discussion: https://www.postgresql.org/message-id/flat/156924954640.1117.6309209869705522549%40wrigleys.postgresql.org
M doc/src/sgml/sources.sgml
doc: Reorder JSON functions documentation
commit : 66e0ea75bb9d4b40c734067dd7c7e1fc804a88cb
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 26 Sep 2019 09:42:19 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 26 Sep 2019 09:42:19 +0200
Put the description of the SQL/JSON path language after the
description of the general JSON functions and operators, instead of
before.
Discussion: https://www.postgresql.org/message-id/16968.1569189812@sss.pgh.pa.us
M doc/src/sgml/func.sgml
Fix handling of GENERATED columns in CREATE TABLE LIKE INCLUDING DEFAULTS.
commit : 658d391d87c13a4b27425a2fd014f2162956ad4d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 25 Sep 2019 17:30:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 25 Sep 2019 17:30:42 -0400
LIKE INCLUDING DEFAULTS tried to copy the attrdef expression without
copying the state of the attgenerated column. This is in fact wrong,
because GENERATED and DEFAULT expressions are not the same kind of animal;
one can contain Vars and the other not. We *must* copy attgenerated
when we're copying the attrdef expression. Rearrange the if-tests
so that the expression is copied only when the correct one of
INCLUDING DEFAULTS and INCLUDING GENERATED has been specified.
Per private report from Manuel Rigger.
Tom Lane and Peter Eisentraut
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
Doc: Fix example related to partition pruning
commit : 37ad1266147626bfe505b2c5b016497605915a8e
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 25 Sep 2019 13:44:43 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 25 Sep 2019 13:44:43 +0900
Append node has been removed in v12 when there would be only one subnode
under it.
Author: Amit Langote
Discussion: https://postgr.es/m/CA+HiwqHhS62w8zUFXF4NBjvMboCXYnD-jWoWp-tfo2aHvP3Gxg@mail.gmail.com
Backpatch-through: 12
M doc/src/sgml/ddl.sgml
Fix failure with lock mode used for custom relation options
commit : 707f38e38e8d4ee891bf52c2f9684f87c72b5234
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 25 Sep 2019 10:08:26 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 25 Sep 2019 10:08:26 +0900
In-core relation options can use a custom lock mode since 47167b7, that
has lowered the lock available for some autovacuum parameters. However
it forgot to consider custom relation options. This causes failures
with ALTER TABLE SET when changing a custom relation option, as its lock
is not defined. The existing APIs to define a custom reloption does not
allow to define a custom lock mode, so enforce its initialization to
AccessExclusiveMode which should be safe enough in all cases. An
upcoming patch will extend the existing APIs to allow a custom lock mode
to be defined.
The problem can be reproduced with bloom indexes, so add a test there.
Reported-by: Nikolay Sharplov
Analyzed-by: Thomas Munro, Michael Paquier
Author: Michael Paquier
Reviewed-by: Kuntal Ghosh
Discussion: https://postgr.es/m/20190920013831.GD1844@paquier.xyz
Backpatch-through: 9.6
M contrib/bloom/expected/bloom.out
M contrib/bloom/sql/bloom.sql
M src/backend/access/common/reloptions.c
Fix bug in pairingheap_SpGistSearchItem_cmp()
commit : 8728552b291b8fe3778346fb4d4b7d1c8743f708
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Wed, 25 Sep 2019 01:47:36 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Wed, 25 Sep 2019 01:47:36 +0300
Our item contains only so->numberOfNonNullOrderBys of distances. Reflect that
in the loop upper bound.
Discussion: https://postgr.es/m/53536807-784c-e029-6e92-6da802ab8d60%40postgrespro.ru
Author: Nikita Glukhov
Backpatch-through: 12
M src/backend/access/spgist/spgscan.c
Stamp 12rc1.
commit : 17822c0e4f5ab8093e78f665c9e44766ae648a44
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 23 Sep 2019 16:24:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 23 Sep 2019 16:24:42 -0400
M configure
M configure.in
M src/include/pg_config.h.win32
Doc: more contributor name cleanup.
commit : 53c89aed7b38ab412fddc1d6118822ce5d962acd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 23 Sep 2019 13:04:52 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 23 Sep 2019 13:04:52 -0400
Further adjust Japanese names, per advice from Etsuro Fujita.
Discussion: https://postgr.es/m/CAPmGK15XT8eCwn1j3tB3CnOn2q6ksHNKwKjDrEcca5ZEfG0tng@mail.gmail.com
M doc/src/sgml/release-12.sgml
Doc: clarify handling of duplicate elements in array containment tests.
commit : 216bcf583802011365b8bb038b4e73f143e857b2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 23 Sep 2019 12:37:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 23 Sep 2019 12:37:04 -0400
The array <@ and @> operators do not worry about duplicates: if every
member of array X matches some element of array Y, then X is contained
in Y, even if several members of X get matched to the same Y member.
This was not explicitly stated in the docs though, so improve matters.
Discussion: https://postgr.es/m/156614120484.1310.310161642239149585@wrigleys.postgresql.org
M doc/src/sgml/func.sgml
Doc: proofreading for v12 release notes.
commit : a25fb9ceb1a63d4383370d4a017aa572d8e99b42
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 23 Sep 2019 10:40:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 23 Sep 2019 10:40:42 -0400
Mostly markup improvements, with a couple of grammar fixes.
Liudmila Mantrova
Discussion: https://postgr.es/m/CAEkD-mDxVV1Hrxzo3-hPaS5b1s-+Gin+9Cbu2eMBqRovRVjC0w@mail.gmail.com
M doc/src/sgml/release-12.sgml
Doc: clean up some issues with spellings of contributor names.
commit : ac8fb2c7e25ce6062d063c56b3c20d24ca581751
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 23 Sep 2019 10:32:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 23 Sep 2019 10:32:02 -0400
In the v12 contributors list, remove a couple of duplicates
that had crept in due to variant spellings of a person's name.
Try to standardize Japanese names as given-name-first.
Alexander Lakhin
Discussion: https://postgr.es/m/a8263c91-6a21-61d4-3156-34bf2fe54e15@gmail.com
M doc/src/sgml/release-12.sgml
Translation updates
commit : 8cdd1c4d07a70df0963a26da2533d4c10852504f
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 23 Sep 2019 15:30:41 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 23 Sep 2019 15:30:41 +0200
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 8a42b829ebeb8b22db0e3258ec02137f8840b960
M src/backend/po/de.po
M src/backend/po/ru.po
M src/bin/initdb/po/ru.po
M src/bin/pg_archivecleanup/po/ru.po
M src/bin/pg_basebackup/po/ru.po
M src/bin/pg_checksums/nls.mk
A src/bin/pg_checksums/po/ru.po
M src/bin/pg_config/po/ru.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_resetwal/po/ru.po
M src/bin/pg_rewind/po/ru.po
M src/bin/pg_test_fsync/po/ru.po
M src/bin/pg_test_timing/po/ru.po
M src/bin/pg_upgrade/po/ru.po
M src/bin/pg_waldump/po/ru.po
M src/bin/psql/po/ru.po
M src/bin/scripts/po/ru.po
M src/interfaces/ecpg/ecpglib/po/ru.po
M src/interfaces/ecpg/preproc/po/ru.po
M src/interfaces/libpq/po/de.po
M src/interfaces/libpq/po/ru.po
M src/pl/plperl/po/ru.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpython/po/ru.po
M src/pl/tcl/po/ru.po
Message style fixes
commit : 516a4c116c5c4206388828f7e2b4e75fa1b1fc87
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 23 Sep 2019 13:37:33 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 23 Sep 2019 13:37:33 +0200
M contrib/test_decoding/expected/slot.out
M src/backend/access/transam/xlog.c
M src/backend/access/transam/xlogfuncs.c
M src/backend/catalog/pg_aggregate.c
M src/backend/libpq/auth.c
M src/backend/replication/basebackup.c
M src/backend/replication/slotfuncs.c
M src/backend/storage/file/fd.c
M src/backend/utils/adt/ri_triggers.c
M src/backend/utils/misc/guc.c
M src/test/regress/expected/foreign_key.out
NLS: Fix backend gettext triggers
commit : 84eb871647b3cc88c89d26d25f0cd84a8ac200fe
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 23 Sep 2019 09:04:20 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 23 Sep 2019 09:04:20 +0200
The backend also needs to pull in translations from the frontend
pg_log_*() functions, since some files in src/common/ use those.
M src/nls-global.mk
Fix failure to zero-pad the result of bitshiftright().
commit : 860216efa10a0b8ba54b84aa370ba5cbc27dd32a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 22 Sep 2019 17:46:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 22 Sep 2019 17:46:00 -0400
If the bitstring length is not a multiple of 8, we'd shift the
rightmost bits into the pad space, which must be zeroes --- bit_cmp,
for one, depends on that. This'd lead to the result failing to
compare equal to what it should compare equal to, as reported in
bug #16013 from Daryl Waycott.
This is, if memory serves, not the first such bug in the bitstring
functions. In hopes of making it the last one, do a bit more work
than minimally necessary to fix the bug:
* Add assertion checks to bit_out() and varbit_out() to complain if
they are given incorrectly-padded input. This will improve the
odds that manual testing of any new patch finds problems.
* Encapsulate the padding-related logic in macros to make it
easier to use.
Also, remove unnecessary padding logic from bit_or() and bitxor().
Somebody had already noted that we need not re-pad the result of
bit_and() since the inputs are required to be the same length,
but failed to extrapolate that to the other two.
Also, move a comment block that once was near the head of varbit.c
(but people kept putting other stuff in front of it), to put it in
the header block.
Note for the release notes: if anyone has inconsistent data as a
result of saving the output of bitshiftright() in a table, it's
possible to fix it with something like
UPDATE mytab SET bitcol = ~(~bitcol) WHERE bitcol != ~(~bitcol);
This has been broken since day one, so back-patch to all supported
branches.
Discussion: https://postgr.es/m/16013-c2765b6996aacae9@postgresql.org
M src/backend/utils/adt/varbit.c
M src/include/utils/varbit.h
M src/test/regress/expected/bit.out
M src/test/regress/sql/bit.sql
Fix typo in tts_virtual_copyslot.
commit : 308813846e737f7d92ffb4e033d65e3df6cbddba
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 22 Sep 2019 14:21:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 22 Sep 2019 14:21:07 -0400
The code used the destination slot's natts where it intended to
use the source slot's natts. Adding an Assert shows that there
is no case in "make check-world" where these counts are different,
so maybe this is a harmless bug, but it's still a bug.
Takayuki Tsunakawa
Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1FD34C0E@G01JPEXMBYT05
M src/backend/executor/execTuples.c
Remove removed file from nls.mk
commit : ee98adede535ed6bd584857d7f5095328a1ce78c
author : Peter Eisentraut <peter@eisentraut.org>
date : Sat, 21 Sep 2019 23:22:15 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sat, 21 Sep 2019 23:22:15 +0200
part of revert "Add DECLARE STATEMENT support to ECPG."
M src/interfaces/ecpg/ecpglib/nls.mk
Update list of acknowledgments in release notes
commit : 87b601605467812c48675a0ec127707bf381cda2
author : Peter Eisentraut <peter@eisentraut.org>
date : Sat, 21 Sep 2019 22:51:54 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sat, 21 Sep 2019 22:51:54 +0200
current through 25f9368304e41c8837f59e94b161f07ac4c7d622
M doc/src/sgml/release-12.sgml
Straighten out leakproofness markings on text comparison functions.
commit : d9110d7e14819c10049c9beb1034958787c77e79
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 21 Sep 2019 16:56:30 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 21 Sep 2019 16:56:30 -0400
Since we introduced the idea of leakproof functions, texteq and textne
were marked leakproof but their sibling text comparison functions were
not. This inconsistency seemed justified because texteq/textne just
relied on memcmp() and so could easily be seen to be leakproof, while
the other comparison functions are far more complex and indeed can
throw input-dependent errors.
However, that argument crashed and burned with the addition of
nondeterministic collations, because now texteq/textne may invoke
the exact same varstr_cmp() infrastructure as the rest. It makes no
sense whatever to give them different leakproofness markings.
After a certain amount of angst we've concluded that it's all right
to consider varstr_cmp() to be leakproof, mostly because the other
choice would be disastrous for performance of many queries where
leakproofness matters. The input-dependent errors should only be
reachable for corrupt input data, or so we hope anyway; certainly,
if they are reachable in practice, we've got problems with requirements
as basic as maintaining a btree index on a text column.
Hence, run around to all the SQL functions that derive from varstr_cmp()
and mark them leakproof. This should result in a useful gain in
flexibility/performance for queries in which non-leakproofness degrades
the efficiency of the query plan.
Back-patch to v12 where nondeterministic collations were added.
While this isn't an essential bug fix given the determination
that varstr_cmp() is leakproof, we might as well apply it now that
we've been forced into a post-beta4 catversion bump.
Discussion: https://postgr.es/m/31481.1568303470@sss.pgh.pa.us
M src/backend/utils/adt/varlena.c
M src/include/catalog/catversion.h
M src/include/catalog/pg_proc.dat
M src/test/regress/expected/opr_sanity.out
M src/test/regress/sql/opr_sanity.sql
Fix up handling of nondeterministic collations with pattern_ops opclasses.
commit : d3c61e88d94cba2070574dccbfba06bbc738c876
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 21 Sep 2019 16:29:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 21 Sep 2019 16:29:17 -0400
text_pattern_ops and its siblings can't be used with nondeterministic
collations, because they use the text_eq operator which will not behave
as bitwise equality if applied with a nondeterministic collation. The
initial implementation of that restriction was to insert a run-time test
in the related comparison functions, but that is inefficient, may throw
misleading errors, and will throw errors in some cases that would work.
It seems sufficient to just prevent the combination during CREATE INDEX,
so do that instead.
Lacking any better way to identify the opclasses involved, we need to
hard-wire tests for them, which requires hand-assigned values for their
OIDs, which forces a catversion bump because they previously had OIDs
that would be assigned automatically. That's slightly annoying in the
v12 branch, but fortunately we're not at rc1 yet, so just do it.
Back-patch to v12 where nondeterministic collations were added.
In passing, run make reformat-dat-files, which found some unrelated
whitespace issues (slightly different ones in HEAD and v12).
Peter Eisentraut, with small corrections by me
Discussion: https://postgr.es/m/22566.1568675619@sss.pgh.pa.us
M src/backend/catalog/index.c
M src/backend/utils/adt/varchar.c
M src/backend/utils/adt/varlena.c
M src/include/catalog/catversion.h
M src/include/catalog/pg_opclass.dat
M src/include/catalog/pg_proc.dat
Doc: updates for v12 release notes.
commit : 25f9368304e41c8837f59e94b161f07ac4c7d622
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 21 Sep 2019 15:23:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 21 Sep 2019 15:23:53 -0400
Remove mention of ECPG's DECLARE STATEMENT, since that was reverted
yesterday. Rewrite some other entries per suggestions from Peter
Eisentraut. Make a couple of desultory wording and markup adjustments.
Discussion: https://postgr.es/m/d4dff575-90ab-9c8c-cc6f-8c657e2de665@2ndquadrant.com
M doc/src/sgml/release-12.sgml
Update time zone data files to tzdata release 2019c.
commit : 2966e30e553b12d2d25aea184f52f9c6ffbcee51
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 20 Sep 2019 19:53:33 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 20 Sep 2019 19:53:33 -0400
DST law changes in Fiji and Norfolk Island. Historical corrections
for Alberta, Austria, Belgium, British Columbia, Cambodia, Hong Kong,
Indiana (Perry County), Kaliningrad, Kentucky, Michigan, Norfolk
Island, South Korea, and Turkey.
M src/timezone/data/tzdata.zi
M src/timezone/known_abbrevs.txt
Fix some minor spec-compliance issues in jsonpath lexer.
commit : 5f3bec0769c1d3c345ee2de30de271dce4feb469
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 20 Sep 2019 14:22:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 20 Sep 2019 14:22:58 -0400
Although the SQL/JSON tech report makes reference to ECMAScript which
allows both single- and double-quoted strings, all the rest of the
report speaks only of double-quoted string literals in jsonpaths.
That's more compatible with JSON itself; moreover single-quoted strings
are hard to use inside a jsonpath that is itself a single-quoted SQL
literal. So guess that the intent is to allow only double-quoted
literals, and remove lexer support for single-quoted literals.
It'll be less painful to add this again later if we're wrong, than to
remove a shipped feature.
Also, adjust the lexer so that unrecognized backslash sequences are
treated as just meaning the escaped character, not as errors. This
change has much better support in the standards, as JSON, JavaScript
and ECMAScript all make it plain that that's what's supposed to
happen.
Back-patch to v12.
Discussion: https://postgr.es/m/CAPpHfdvDci4iqNF9fhRkTqhe-5_8HmzeLt56drH%2B_Rv2rNRqfg@mail.gmail.com
M src/backend/utils/adt/jsonpath_scan.l
M src/test/regress/expected/jsonpath.out
M src/test/regress/expected/jsonpath_encoding.out
M src/test/regress/expected/jsonpath_encoding_1.out
M src/test/regress/sql/jsonpath.sql
M src/test/regress/sql/jsonpath_encoding.sql
Revert "Add DECLARE STATEMENT support to ECPG."
commit : 08e04a5f99d50285edf8e89a18da67ce2d75d676
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 20 Sep 2019 12:47:21 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 20 Sep 2019 12:47:21 -0400
This reverts commit bd7c95f0c1a38becffceb3ea7234d57167f6d4bf,
along with assorted follow-on fixes. There are some questions
about the definition and implementation of that statement, and
we don't have time to resolve them before v13 release. Rather
than ship the feature and then have backwards-compatibility
concerns constraining any redesign, let's remove it for now
and try again later.
Discussion: https://postgr.es/m/TY2PR01MB2443EC8286995378AEB7D9F8F5B10@TY2PR01MB2443.jpnprd01.prod.outlook.com
M doc/src/sgml/ecpg.sgml
M src/interfaces/ecpg/ecpglib/Makefile
M src/interfaces/ecpg/ecpglib/connect.c
D src/interfaces/ecpg/ecpglib/cursor.c
M src/interfaces/ecpg/ecpglib/descriptor.c
M src/interfaces/ecpg/ecpglib/ecpglib_extern.h
M src/interfaces/ecpg/ecpglib/error.c
M src/interfaces/ecpg/ecpglib/execute.c
M src/interfaces/ecpg/ecpglib/exports.txt
M src/interfaces/ecpg/ecpglib/prepare.c
M src/interfaces/ecpg/include/ecpgerrno.h
M src/interfaces/ecpg/include/ecpglib.h
M src/interfaces/ecpg/include/ecpgtype.h
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/ecpg.type
M src/interfaces/ecpg/preproc/output.c
M src/interfaces/ecpg/preproc/preproc_extern.h
M src/interfaces/ecpg/preproc/type.h
M src/interfaces/ecpg/test/ecpg_schedule
M src/interfaces/ecpg/test/expected/compat_informix-sqlda.c
M src/interfaces/ecpg/test/expected/compat_informix-test_informix.c
M src/interfaces/ecpg/test/expected/compat_oracle-char_array.c
M src/interfaces/ecpg/test/expected/pgtypeslib-nan_test.c
M src/interfaces/ecpg/test/expected/preproc-autoprep.c
M src/interfaces/ecpg/test/expected/preproc-cursor.c
M src/interfaces/ecpg/test/expected/preproc-outofscope.c
M src/interfaces/ecpg/test/expected/preproc-variable.c
M src/interfaces/ecpg/test/expected/preproc-whenever_do_continue.c
M src/interfaces/ecpg/test/expected/sql-binary.c
D src/interfaces/ecpg/test/expected/sql-declare.c
D src/interfaces/ecpg/test/expected/sql-declare.stderr
D src/interfaces/ecpg/test/expected/sql-declare.stdout
M src/interfaces/ecpg/test/expected/sql-desc.c
M src/interfaces/ecpg/test/expected/sql-dyntest.c
M src/interfaces/ecpg/test/expected/sql-execute.c
M src/interfaces/ecpg/test/expected/sql-fetch.c
M src/interfaces/ecpg/test/expected/sql-oldexec.c
M src/interfaces/ecpg/test/expected/sql-quote.c
M src/interfaces/ecpg/test/expected/sql-sqlda.c
M src/interfaces/ecpg/test/sql/.gitignore
M src/interfaces/ecpg/test/sql/Makefile
D src/interfaces/ecpg/test/sql/declare.pgc
Fix progress report of REINDEX INDEX
commit : c3c131e295af6530381a8ace749c81fcc8930059
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 20 Sep 2019 12:53:58 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 20 Sep 2019 12:53:58 -0300
I (Álvaro) broke that in commit 6212276e4343 -- forgot to set the
necessary flag. Repair.
Author: Amit Langote
Discussion: https://postgr.es/m/CA+HiwqEaM2tV5awKhP1vSbgjQe_uXVU15Oi4sTgwgempwMiT8g@mail.gmail.com
M src/backend/commands/indexcmds.c
Provide stable test for NULL-values in KNN SP-GiST
commit : d75386a3fd34d8902667474318c2ebe40978de32
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Fri, 20 Sep 2019 15:31:12 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Fri, 20 Sep 2019 15:31:12 +0300
f5f084fc3e has removed test because of its instability. This commit provides
alternative test with determined ordering using extra ORDER BY expression.
Backpatch-through: 12
M src/test/regress/expected/create_index_spgist.out
M src/test/regress/sql/create_index_spgist.sql
Fix typo in commit 82fa3ff8672.
commit : 09f8106b968e10c7855c0a9fd07dd3520d30e4eb
author : Amit Kapila <akapila@postgresql.org>
date : Fri, 20 Sep 2019 07:38:06 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Fri, 20 Sep 2019 07:38:06 +0530
Reported-By: Kuntal Ghosh (off-list)
Backpatch-through: 9.4, like 82fa3ff8672
M doc/src/sgml/maintenance.sgml
Remove unstable KNN SP-GiST test
commit : 340536dd489286d0f98878843390d92ddc593be0
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Fri, 20 Sep 2019 01:46:49 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Fri, 20 Sep 2019 01:46:49 +0300
6cae9d2c10 introduced test for NULL values in KNN SP-GiST. This test relies on
undetermined ordering showing different results on various platforms. This
commit removes that test. Will be replaced with better test later.
Discussion: https://postgr.es/m/6d51305e1159241cabee132f7efc7eff%40xs4all.nl
Backpatch-through: 12
M src/test/regress/expected/create_index_spgist.out
M src/test/regress/sql/create_index_spgist.sql
Fix freeing old values in index_store_float8_orderby_distances()
commit : 8c58e480d9ddecbe94badc737d60c866974144b5
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Fri, 20 Sep 2019 01:10:56 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Fri, 20 Sep 2019 01:10:56 +0300
6cae9d2c10 has added an error in freeing old values in
index_store_float8_orderby_distances() function. It looks for old value in
scan->xs_orderbynulls[i] after setting a new value there.
This commit fixes that. Also it removes short-circuit in handling
distances == NULL situation. Now distances == NULL will be treated the same
way as array with all null distances. That is, previous values will be freed
if any.
Reported-by: Tom Lane, Nikita Glukhov
Discussion: https://postgr.es/m/CAPpHfdu2wcoAVAm3Ek66rP%3Duo_C-D84%2B%2Buf1VEcbyi_caBXWCA%40mail.gmail.com
Discussion: https://postgr.es/m/426580d3-a668-b9d1-7b8e-f74d1a6524e0%40postgrespro.ru
Backpatch-through: 12
M src/backend/access/index/indexam.c
Improve handling of NULLs in KNN-GiST and KNN-SP-GiST
commit : 31cbd760578fc0aeb87db11422c32afaf5de129b
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Thu, 19 Sep 2019 21:30:19 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Thu, 19 Sep 2019 21:30:19 +0300
This commit improves subject in two ways:
* It removes ugliness of 02f90879e7, which stores distance values and null
flags in two separate arrays after GISTSearchItem struct. Instead we pack
both distance value and null flag in IndexOrderByDistance struct. Alignment
overhead should be negligible, because we typically deal with at most few
"col op const" expressions in ORDER BY clause.
* It fixes handling of "col op NULL" expression in KNN-SP-GiST. Now, these
expression are not passed to support functions, which can't deal with them.
Instead, NULL result is implicitly assumed. It future we may decide to
teach support functions to deal with NULL arguments, but current solution is
bugfix suitable for backpatch.
Reported-by: Nikita Glukhov
Discussion: https://postgr.es/m/826f57ee-afc7-8977-c44c-6111d18b02ec%40postgrespro.ru
Author: Nikita Glukhov
Reviewed-by: Alexander Korotkov
Backpatch-through: 9.4
M src/backend/access/gist/gistget.c
M src/backend/access/gist/gistscan.c
M src/backend/access/index/indexam.c
M src/backend/access/spgist/spgscan.c
M src/include/access/genam.h
M src/include/access/gist_private.h
M src/include/access/spgist_private.h
M src/test/regress/expected/create_index_spgist.out
M src/test/regress/sql/create_index_spgist.sql
M src/tools/pgindent/typedefs.list
Doc: improve documentation around jsonpath regular expressions.
commit : b9cf94c8c2496af30dcdf7cea083463f6464dff0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 19 Sep 2019 11:22:21 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 19 Sep 2019 11:22:21 -0400
Provide some documentation about the differences between XQuery
regular expressions and those supported by Spencer's regex engine.
Since SQL now exposes XQuery regexps with the LIKE_REGEX operator,
I made this a standalone section designed to help somebody who
has to translate a LIKE_REGEX query to Postgres. (Eventually we might
extend Spencer's engine to allow precise implementation of XQuery,
but not today.)
Reference that in the jsonpath docs, provide definitions of the
XQuery flag letters, and add a description of the JavaScript-inspired
string literal syntax used within jsonpath. Also point out explicitly
that backslashes used within like_regex patterns will need to be doubled.
This also syncs the docs with the decision implemented in commit
d5b90cd64 to desupport XQuery's 'x' flag for now.
Jonathan Katz and Tom Lane
Discussion: https://postgr.es/m/CAPpHfdvDci4iqNF9fhRkTqhe-5_8HmzeLt56drH%2B_Rv2rNRqfg@mail.gmail.com
M doc/src/sgml/func.sgml
M doc/src/sgml/json.sgml
GSSAPI error message improvements
commit : 596cf9e806826936869f62232bd011687c467965
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 19 Sep 2019 15:03:23 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 19 Sep 2019 15:03:23 +0200
Make the error messages around GSSAPI encryption a bit clearer. Tweak
some messages to avoid plural problems.
Also make a code change for clarity. Using "conf" for "confidential"
is quite confusing. Using "conf_state" is perhaps not much better but
that's what the GSSAPI documentation uses, so there is at least some
hope of understanding it.
M src/backend/libpq/be-secure-gssapi.c
M src/interfaces/libpq/fe-secure-gssapi.c
doc: Improve a release notes item
commit : 9c4f20066fb20197dfc20e3cf31aa3c890f3646b
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 19 Sep 2019 11:46:40 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 19 Sep 2019 11:46:40 +0200
M doc/src/sgml/release-12.sgml
Fix typo in commit 578b229718.
commit : a4188a65be9426136fc176430ea646cb0fa04fff
author : Amit Kapila <akapila@postgresql.org>
date : Thu, 19 Sep 2019 14:40:09 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Thu, 19 Sep 2019 14:40:09 +0530
Reported-by: Filip Rembiałkowski
Author: Filip Rembiałkowski
Backpatch-through: 12, where it was introduced
Discussion: https://postgr.es/m/CAP_rwwmSNy1=_82rwGe3-X4PjWqPSFXtzNf43DCtGzD7SazdXA@mail.gmail.com
M doc/src/sgml/ref/create_table_as.sgml
doc: Some release notes tweaking
commit : 1aaa3ee34466780d6f050b7d4aa5cc69935c08b5
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 19 Sep 2019 09:58:43 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 19 Sep 2019 09:58:43 +0200
Improve the LDAP DNS SRV item.
M doc/src/sgml/release-12.sgml
Revert change of ecpglib major version
commit : fbd1cb2fd9796a08a198d929774280ecce933057
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 19 Sep 2019 09:02:41 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 19 Sep 2019 09:02:41 +0200
The major version of ecpglib was changed in
bd7c95f0c1a38becffceb3ea7234d57167f6d4bf, apparently without
justification. Revert this, since nothing has changed in this library
except some added functions.
Discussion: https://www.postgresql.org/message-id/flat/48ee4c56-e1df-b39d-2cad-c7d80b120eb5%402ndquadrant.com
M src/interfaces/ecpg/ecpglib/Makefile
Doc: Fix incorrect mention to connection_object in CONNECT command of ECPG
commit : ae2d826922b745ea2c77c51019948ccf4309f50f
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 19 Sep 2019 13:19:00 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 19 Sep 2019 13:19:00 +0900
This fixes an inconsistency with this parameter name not listed in the
command synopsis, and connection_name is the parameter name more
commonly used in the docs for ECPG commands.
Reported-by: Yusuke Egashita
Discussion: https://postgr.es/m/156870956796.1259.11456186889345212399@wrigleys.postgresql.org
Backpatch-through: 9.4
M doc/src/sgml/ecpg.sgml
Doc: document autovacuum interruption.
commit : 62ed5e77f3dc6d8c65d917b60dc8512ddd6fd18e
author : Amit Kapila <akapila@postgresql.org>
date : Thu, 19 Sep 2019 08:02:12 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Thu, 19 Sep 2019 08:02:12 +0530
It's important users be able to know (without looking at the source code)
that running DDL or DDL-like commands can interrupt autovacuum which can
lead to a lot of dead tuples and hence slower database operations.
Reported-by: James Coleman
Author: James Coleman
Reviewed-by: Amit Kapila
Backpatch-through: 9.4
Discussion: https://postgr.es/m/CAAaqYe-XYyNwML1=f=gnd0qWg46PnvD=BDrCZ5-L94B887XVxQ@mail.gmail.com
M doc/src/sgml/maintenance.sgml
pg_upgrade/test.sh: Quote sed(1) argument
commit : cb23c63bc6de3ecef2a6a9d58d44640865472da4
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 18 Sep 2019 11:24:12 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 18 Sep 2019 11:24:12 -0300
Lack of quotes results in failure to run the test under older Solaris.
Author: Marina Polyakova, Victor Wagner
Discussion: https://postgr.es/m/feba89f89e8925b3535cb7d72b9e05e1@postgrespro.ru
M src/bin/pg_upgrade/test.sh
Doc: Update FDW documentation about direct foreign table modification.
commit : 68c3c493674d81131c8f2685b91ec8de4fdcb862
author : Etsuro Fujita <efujita@postgresql.org>
date : Wed, 18 Sep 2019 18:50:01 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Wed, 18 Sep 2019 18:50:01 +0900
1. Commit 7086be6e3 should have documented the limitation that the direct
modification is disabled when WCO constraints are present, but didn't,
which is definitely my fault. Update the documentation (Postgres 9.6
onwards).
2. Commit fc22b6623 should have documented the limitation that the direct
modification is disabled when generated columns are defined, but
didn't. Update the documentation (Postgres 12 onwards).
Author: Etsuro Fujita
Discussion: https://postgr.es/m/CAPmGK14AYCPunLb6TRz1CQsW5Le01Z2ox8LSOKH0P-cOVDcQRA%40mail.gmail.com
M doc/src/sgml/fdwhandler.sgml
M doc/src/sgml/postgres-fdw.sgml
Fix bogus handling of XQuery regex option flags.
commit : 14888145420802a32ec018246e12f3b377c61c29
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 17 Sep 2019 15:39:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 17 Sep 2019 15:39:51 -0400
The SQL spec defers to XQuery to define what the option flags are
for LIKE_REGEX patterns. XQuery says that:
* 's' allows the dot character to match newlines, which by
default it will not;
* 'm' allows ^ and $ to match at newlines, not only at the
start/end of the whole string.
Thus, these are *not* inverses as they are for the similarly-named
POSIX options, and neither one corresponds to the POSIX 'n' option.
Fortunately, Spencer's library does expose these two behaviors as
separately twiddlable flags, so we just have to fix the mapping from
JSP flag bits to REG flag bits. I also chose to rename the symbol
for 's' to DOTALL, to make it clearer that it's not the inverse
of MLINE.
Also, XQuery says that if the 'q' flag "is used together with the m, s,
or x flag, that flag has no effect". I read this as saying that 'q'
overrides the other flags; whoever wrote our code seems to have read
it backwards.
Lastly, while XQuery's 'x' flag is related to what Spencer's code
does for REG_EXPANDED, it's not the same or a subset. It seems best
to treat XQuery's 'x' as unimplemented for now. Maybe later we can
expand our regex code to offer 'x'-style parsing as a separate option.
While at it, refactor the jsonpath code so that (a) there's only
one copy of the flag transformation logic not two, and (b) the
processing of flags is independent of the order in which the flags
are written.
We need some documentation updates to go with this, but I'll
tackle that separately.
Back-patch to v12 where this code originated.
Discussion: https://postgr.es/m/CAPpHfdvDci4iqNF9fhRkTqhe-5_8HmzeLt56drH%2B_Rv2rNRqfg@mail.gmail.com
Reference: https://www.w3.org/TR/2017/REC-xpath-functions-31-20170321/#flags
M src/backend/utils/adt/jsonpath.c
M src/backend/utils/adt/jsonpath_exec.c
M src/backend/utils/adt/jsonpath_gram.y
M src/include/utils/jsonpath.h
M src/test/regress/expected/jsonb_jsonpath.out
M src/test/regress/expected/jsonpath.out
M src/test/regress/sql/jsonb_jsonpath.sql
Fix bogus sizeof calculations.
commit : 27bc87985c4135f27bdcddd905baad3b62a3f03a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 15 Sep 2019 11:51:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 15 Sep 2019 11:51:57 -0400
Noted by Coverity. Typo in 27cc7cd2b, so back-patch to v12
as that was.
M src/backend/executor/execMain.c
Fix intermittent self-test failures caused by the stats_ext test.
commit : 5576cbc8ff1f8b34e519e54ef43de68ed1b2f93e
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sun, 15 Sep 2019 13:16:59 +0100
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sun, 15 Sep 2019 13:16:59 +0100
Commit d7f8d26d9 added new tests to the stats_ext regression test that
included creating a view in the public schema, without realising that
the stats_ext test runs in the same parallel group as the rules test,
which makes doing that unsafe.
This led to intermittent failures of the rules test on the buildfarm,
although I wasn't able to reproduce that locally. Fix by creating the
view in a different schema.
Tomas Vondra and Dean Rasheed, report and diagnosis by Thomas Munro.
Discussion: https://postgr.es/m/CA+hUKGKX9hFZrYA7rQzAMRE07L4hziCc-nO_b3taJpiuKyLLxg@mail.gmail.com
M src/test/regress/expected/stats_ext.out
M src/test/regress/sql/stats_ext.sql
Replace xlc __fetch_and_add() with inline asm.
commit : 1c6b62a7d0e57bf9ac7a91d47484b1ea9f2857cd
author : Noah Misch <noah@leadboat.com>
date : Fri, 13 Sep 2019 19:34:06 -0700
committer: Noah Misch <noah@leadboat.com>
date : Fri, 13 Sep 2019 19:34:06 -0700
PostgreSQL has been unusable when built with xlc 13 and newer, which are
incompatible with our use of __fetch_and_add(). Back-patch to 9.5,
which introduced pg_atomic_fetch_add_u32().
Reviewed by Tom Lane.
Discussion: https://postgr.es/m/20190831071157.GA3251746@rfd.leadboat.com
M src/include/port/atomics/generic-xlc.h
Test pg_atomic_fetch_add_ with variable addend and 16-bit edge cases.
commit : 5b5b0f721d9cece8fb68ecdd1d53c3bffe6e753c
author : Noah Misch <noah@leadboat.com>
date : Fri, 13 Sep 2019 19:33:30 -0700
committer: Noah Misch <noah@leadboat.com>
date : Fri, 13 Sep 2019 19:33:30 -0700
Back-patch to 9.5, which introduced these functions.
Reviewed by Tom Lane.
Discussion: https://postgr.es/m/20190831071157.GA3251746@rfd.leadboat.com
M src/test/regress/regress.c
logical decoding: process ASSIGNMENT during snapshot build
commit : 96b5033e117141eecf3782ee555f39b3006a732f
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 13 Sep 2019 16:36:28 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 13 Sep 2019 16:36:28 -0300
Most WAL records are ignored in early SnapBuild snapshot build phases.
But it's critical to process some of them, so that later messages have
the correct transaction state after the snapshot is completely built; in
particular, XLOG_XACT_ASSIGNMENT messages are critical in order for
sub-transactions to be correctly assigned to their parent transactions,
or at least one assert misbehaves, as reported by Ildar Musin.
Diagnosed-by: Masahiko Sawada
Author: Masahiko Sawada
Discussion: https://postgr.es/m/CAONYFtOv+Er1p3WAuwUsy1zsCFrSYvpHLhapC_fMD-zNaRWxYg@mail.gmail.com
M src/backend/replication/logical/decode.c
Fix under-parenthesized macro definitions
commit : a0a40f611e9af81507a48f7fd96833ad57c8e4ae
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 13 Sep 2019 16:26:55 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 13 Sep 2019 16:26:55 -0300
Lack of parens in the definitions could cause a statement using these
macros to have unexpected semantics. In current code no bug is
apparent, but best to fix the definitions to avoid problems down the
line.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/19795.1568400476@sss.pgh.pa.us
M src/include/nodes/parsenodes.h
Fix progress reporting of CLUSTER / VACUUM FULL
commit : da47e43dc32e3c5916396f0cbcfa974b371e4875
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 13 Sep 2019 14:51:13 -0300
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 13 Sep 2019 14:51:13 -0300
The progress state was being clobbered once the first index completed
being rebuilt, causing the final phases of the operation not show
anything in the progress view. This was inadvertently broken in
03f9e5cba0ee, which added progress tracking for REINDEX.
(The reason this bugfix is this small is that I had already noticed this
problem when writing monitoring for CREATE INDEX, and had already worked
around it, as can be seen in discussion starting at
https://postgr.es/m/20190329150218.GA25010@alvherre.pgsql Fixing the
problem is just a matter of fixing one place touched by the REINDEX
monitoring.)
Reported by: Álvaro Herrera
Author: Álvaro Herrera
Discussion: https://postgr.es/m/20190801184333.GA21369@alvherre.pgsql
M src/backend/catalog/index.c
M src/backend/commands/indexcmds.c
M src/include/nodes/parsenodes.h
Typo fixes for documentation
commit : 6eb9b20bb7dd770c78bf43b205b98e15972e2341
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Fri, 13 Sep 2019 17:21:20 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Fri, 13 Sep 2019 17:21:20 +0300
Discussion: https://postgr.es/m/CAEkD-mDUZrRE%3Dk-FznEg4Ed2VdjpZCyHoyo%2Bp0%2B8KvHqR%3DpNVQ%40mail.gmail.com
Author: Liudmila Mantrova, Alexander Lakhin
Reviewed-by: Alexander Korotkov, Alvaro Herrera
Backpatch-through: 12
M doc/src/sgml/charset.sgml
M doc/src/sgml/config.sgml
M doc/src/sgml/func.sgml
Documentation improvements to jsonpath
commit : 9f771868c446c44dae6b97c68eeb1b19da32c50a
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Fri, 13 Sep 2019 17:12:20 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Fri, 13 Sep 2019 17:12:20 +0300
Besides cosmetic improvements it removes statement that operators necessary
need to be separated from operands with spaces, which is not really true.
Discussion: https://postgr.es/m/CAEkD-mDUZrRE%3Dk-FznEg4Ed2VdjpZCyHoyo%2Bp0%2B8KvHqR%3DpNVQ%40mail.gmail.com
Author: Liudmila Mantrova, Alexander Lakhin
Reviewed-by: Alexander Korotkov, Alvaro Herrera
Backpatch-through: 12
M doc/src/sgml/func.sgml
M doc/src/sgml/json.sgml
Fix nbtree page split rmgr desc routine.
commit : 3097a0d6e9e28137691a2e89949f1b525160de2d
author : Peter Geoghegan <pg@bowt.ie>
date : Thu, 12 Sep 2019 15:45:07 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Thu, 12 Sep 2019 15:45:07 -0700
Include newitemoff in rmgr desc output for nbtree page split records.
In passing, correct an obsolete comment that claimed that newitemoff is
only logged for _L variant nbtree page split WAL records.
Both issues were oversights in commit 2c03216d831, which revamped the
WAL format.
Author: Peter Geoghegan
Backpatch: 9.5-, where the WAL format was revamped.
M src/backend/access/rmgrdesc/nbtdesc.c
M src/include/access/nbtxlog.h
Fix usage of whole-row variables in WCO and RLS policy expressions.
commit : 5e9b18c78789aa905d7aba8e0f0729e965aa32fd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 Sep 2019 18:29:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 12 Sep 2019 18:29:17 -0400
Since WITH CHECK OPTION was introduced, ExecInitModifyTable has
initialized WCO expressions with the wrong plan node as parent -- that is,
it passed its input subplan not the ModifyTable node itself. Up to now
we thought this was harmless, but bug #16006 from Vinay Banakar shows it's
not: if the input node is a SubqueryScan then ExecInitWholeRowVar can get
confused into doing the wrong thing. (The fact that ExecInitWholeRowVar
contains such logic is certainly a horrid kluge that doesn't deserve to
live, but figuring out another way to do that is a task for some other day.)
Andres had already noticed the wrong-parent mistake and fixed it in commit
148e632c0, but not being aware of any user-visible consequences, he quite
reasonably didn't back-patch. This patch is simply a back-patch of
148e632c0, plus addition of a test case based on bug #16006. I also added
the test case to v12/HEAD, even though the bug is already fixed there.
Back-patch to all supported branches. 9.4 lacks RLS policies so the
new test case doesn't work there, but I'm pretty sure a test could be
devised based on using a whole-row Var in a plain WITH CHECK OPTION
condition. (I lack the cycles to do so myself, though.)
Andres Freund and Tom Lane
Discussion: https://postgr.es/m/16006-99290d2e4642cbd5@postgresql.org
Discussion: https://postgr.es/m/20181205225213.hiwa3kgoxeybqcqv@alap3.anarazel.de
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Doc: Update PL/pgSQL sample function in plpgsql.sgml.
commit : fef55c569eeda4286451f4fb884ad7d3b1de29fd
author : Amit Kapila <akapila@postgresql.org>
date : Wed, 11 Sep 2019 10:25:49 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Wed, 11 Sep 2019 10:25:49 +0530
The example used to explain 'Looping Through Query Results' uses
pseudo-materialized views. Replace it with a more up-to-date example
which does the same thing with actual materialized views, which have
been available since PostgreSQL 9.3.
In the passing, change '%' as format specifier instead of '%s' as is used
in other examples in plpgsql.sgml.
Reported-by: Ian Barwick
Author: Ian Barwick
Reviewed-by: Amit Kapila
Backpatch-through: 9.4
Discussion: https://postgr.es/m/9a70d393-7904-4918-c97c-649f6d114b6a@2ndquadrant.com
M doc/src/sgml/plpgsql.sgml
Expand properly list of TAP tests used for prove in vcregress.pl
commit : dc92bf5cad7ccae294ec7055382c7727726702cc
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 11 Sep 2019 11:07:25 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 11 Sep 2019 11:07:25 +0900
Depending on the system used, t/*.pl may not be expanded into a list of
tests which can be consumed by prove when attempting to run TAP tests on
a given path. Fix that by using glob() directly in the script, to make
sure that a complete list of tests is provided. This has not proved to
be an issue with MSVC as the list was properly expanded, but it is on
Linux with perl's system().
This is extracted from a larger patch.
Author: Tom Lane
Discussion: https://postgr.es/m/6628.1567958876@sss.pgh.pa.us
Backpatch-through: 9.4
M src/tools/msvc/vcregress.pl
Don't drop NOTICE messages in isolation tests.
commit : b1016834d325dff5eb168e5f6f261462eb6f1d56
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 10 Sep 2019 12:04:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 10 Sep 2019 12:04:57 -0400
For its entire existence, isolationtester.c has forced client_min_messages
to WARNING, but that seems like a very poor choice of test design. It
should be up to individual test scripts to manage whether they emit notices
and to ensure that the results are stable. (There were no NOTICE messages
in the original set of isolation tests, so this was certainly dead code
when committed, but perhaps it was needed at some earlier point.)
It's possible that the original motivation was due to platform-dependent
variations in the timing of stdout vs. stderr output. That should be
moot since commits 73bcb76b7/6eda3e9c2, but just in case, adjust
isotesterNoticeProcessor to print to stdout not stderr. (stderr seems
like the wrong thing anyway: it should be for error printouts not expected
test output.)
Back-patch of commit ebd499282 into v12. I'll separately push this
into older branches, but this is as much change as v12 needs.
Discussion: https://postgr.es/m/14616.1564251339@sss.pgh.pa.us
Discussion: https://postgr.es/m/E1i7IqC-0000Uc-5H@gemulon.postgresql.org
M src/test/isolation/expected/insert-conflict-specconflict.out
M src/test/isolation/expected/plpgsql-toast.out
M src/test/isolation/isolationtester.c
M src/test/isolation/specs/plpgsql-toast.spec
Fix isolationtester race condition for notices sent before blocking.
commit : 97fb88ea4a646343d5f0a8cd65b7e5f598785cb4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 Sep 2019 22:53:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 Sep 2019 22:53:51 -0400
If a test sends a notice just before blocking, it's possible on
slow machines for isolationtester to detect the blocked state before
it's consumed the notice. (For this to happen, the notice would have
to arrive after isolationtester has waited for data for 10ms, so on
fast/lightly-loaded machines it's hard to reproduce the failure.)
But, if we have seen the backend as blocked, it's certainly already
sent any notices it's going to send. Therefore, one more round of
PQconsumeInput and PQisBusy should be enough to collect and process
any such notices.
Back-patch of 30717637c into v12. We're still discussing whether
to back-patch this further and/or back-patch some other recent
isolationtester fixes, but this much is provably necessary to
make the test cases added by 27cc7cd2b stable in v12.
Discussion: https://postgr.es/m/14616.1564251339@sss.pgh.pa.us
Discussion: https://postgr.es/m/E1i7IqC-0000Uc-5H@gemulon.postgresql.org
M src/test/isolation/isolationtester.c
Stamp 12beta4.
commit : 84bb33c4804ea26b3f23df875701731bd01d3f0a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 Sep 2019 16:24:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 Sep 2019 16:24:29 -0400
M configure
M configure.in
M src/include/pg_config.h.win32
Be more careful about port selection in src/test/ldap/.
commit : 5348e22b969f6af8bd4400256a6a190721a01f34
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 Sep 2019 14:21:40 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 9 Sep 2019 14:21:40 -0400
Don't just assume that the next port is free; it might not be, or
if we're really unlucky it might even be out of the TCP range.
Do it honestly with two get_free_port() calls instead.
This is surely a pretty low-probability problem, but I think it
explains a buildfarm failure seen today, so let's fix it.
Back-patch to v11 where this script was added.
Discussion: https://postgr.es/m/25124.1568052346@sss.pgh.pa.us
M src/test/ldap/t/001_auth.pl
Prevent msys2 conversion of "cmd /c" switch to a file path
commit : 9668b02f80425dc72116101cb368c6ac1cc210a1
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 9 Sep 2019 08:56:33 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 9 Sep 2019 08:56:33 -0400
Modern versions of msys2 have changed the treatment of "cmd /c" so that
the runtime will try to convert the switch to a native file path. This
patch adds a setting to inhibit that behaviour.
Discussion: https://postgr.es/m/3227042f-cfcc-745a-57dd-fb8c471f8ddf@2ndQuadrant.com
Backpatch to all live branches.
M src/bin/pg_upgrade/test.sh
Always skip recovery SysV shared memory tests on Windows
commit : 7d49803259de7514e16dfdf2b6a36e7b514f0505
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 9 Sep 2019 08:42:06 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 9 Sep 2019 08:42:06 -0400
These tests were disabled on git master in commit 8e5ce1c3f8. This does
the same thing on the back branches.
Discussion: https://postgr.es/m/a1c40fab-a38c-cb42-6879-125f834e837b@2ndQuadrant.com
M src/test/recovery/t/017_shm.pl
Reorder EPQ work, to fix rowmark related bugs and improve efficiency.
commit : 3fb307bc4a76815f96fec28a0d1525ab3fbbcfb4
author : Andres Freund <andres@anarazel.de>
date : Mon, 9 Sep 2019 05:21:30 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 9 Sep 2019 05:21:30 -0700
In ad0bda5d24ea I changed the EvalPlanQual machinery to store
substitution tuples in slot, instead of using plain HeapTuples. The
main motivation for that was that using HeapTuples will be inefficient
for future tableams. But it turns out that that conversion was buggy
for non-locking rowmarks - the wrong tuple descriptor was used to
create the slot.
As a secondary issue 5db6df0c0 changed ExecLockRows() to begin EPQ
earlier, to allow to fetch the locked rows directly into the EPQ
slots, instead of having to copy tuples around. Unfortunately, as Tom
complained, that forces some expensive initialization to happen
earlier.
As a third issue, the test coverage for EPQ was clearly insufficient.
Fixing the first issue is unfortunately not trivial: Non-locked row
marks were fetched at the start of EPQ, and we don't have the type
information for the rowmarks available at that point. While we could
change that, it's not easy. It might be worthwhile to change that at
some point, but to fix this bug, it seems better to delay fetching
non-locking rowmarks when they're actually needed, rather than
eagerly. They're referenced at most once, and in cases where EPQ
fails, might never be referenced. Fetching them when needed also
increases locality a bit.
To be able to fetch rowmarks during execution, rather than
initialization, we need to be able to access the active EPQState, as
that contains necessary data. To do so move EPQ related data from
EState to EPQState, and, only for EStates creates as part of EPQ,
reference the associated EPQState from EState.
To fix the second issue, change EPQ initialization to allow use of
EvalPlanQualSlot() to be used before EvalPlanQualBegin() (but
obviously still requiring EvalPlanQualInit() to have been done).
As these changes made struct EState harder to understand, e.g. by
adding multiple EStates, significantly reorder the members, and add a
lot more comments.
Also add a few more EPQ tests, including one that fails for the first
issue above. More is needed.
Reported-By: yi huang
Author: Andres Freund
Reviewed-By: Tom Lane
Discussion:
https://postgr.es/m/CAHU7rYZo_C4ULsAx_LAj8az9zqgrD8WDd4hTegDTMM1LMqrBsg@mail.gmail.com
https://postgr.es/m/24530.1562686693@sss.pgh.pa.us
Backpatch: 12-, where the EPQ changes were introduced
M src/backend/commands/trigger.c
M src/backend/executor/execMain.c
M src/backend/executor/execScan.c
M src/backend/executor/execUtils.c
M src/backend/executor/nodeIndexonlyscan.c
M src/backend/executor/nodeIndexscan.c
M src/backend/executor/nodeLockRows.c
M src/backend/executor/nodeModifyTable.c
M src/include/executor/executor.h
M src/include/nodes/execnodes.h
M src/test/isolation/expected/eval-plan-qual.out
M src/test/isolation/specs/eval-plan-qual.spec
Fix handling of non-key columns get_index_column_opclass()
commit : c6ce5f71b08235f9ed8e0206267ae560ea1ebc91
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 9 Sep 2019 13:50:12 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 9 Sep 2019 13:50:12 +0300
f2e40380 introduces support of non-key attributes in GiST indexes. Then if
get_index_column_opclass() is asked by gistproperty() to get an opclass of
non-key column, it returns garbage past oidvector value. This commit fixes
that by making get_index_column_opclass() return InvalidOid in this case.
Discussion: https://postgr.es/m/20190902231948.GA5343%40alvherre.pgsql
Author: Nikita Glukhov, Alexander Korotkov
Backpatch-through: 12
M src/backend/utils/cache/lsyscache.c
Translation updates
commit : 55a808c1a899380bff3340ed8d896d06f0b19f9b
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 9 Sep 2019 11:34:06 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 9 Sep 2019 11:34:06 +0200
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 2808de890d4be52a0a82fb3bd84ea7998c6f5101
M src/backend/po/de.po
M src/backend/po/ru.po
M src/backend/po/sv.po
M src/bin/initdb/po/de.po
M src/bin/pg_basebackup/po/de.po
M src/bin/pg_checksums/po/de.po
M src/bin/pg_checksums/po/sv.po
M src/bin/pg_config/nls.mk
M src/bin/pg_config/po/de.po
M src/bin/pg_config/po/ru.po
A src/bin/pg_config/po/uk.po
M src/bin/pg_controldata/nls.mk
M src/bin/pg_controldata/po/ru.po
A src/bin/pg_controldata/po/uk.po
M src/bin/pg_ctl/nls.mk
M src/bin/pg_ctl/po/de.po
M src/bin/pg_ctl/po/ru.po
A src/bin/pg_ctl/po/uk.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_dump/po/sv.po
M src/bin/pg_rewind/po/de.po
M src/bin/pg_test_fsync/nls.mk
A src/bin/pg_test_fsync/po/uk.po
M src/bin/pg_test_timing/nls.mk
A src/bin/pg_test_timing/po/uk.po
M src/bin/pg_upgrade/po/de.po
M src/bin/psql/nls.mk
M src/bin/psql/po/de.po
M src/bin/psql/po/ru.po
M src/bin/psql/po/sv.po
A src/bin/psql/po/uk.po
M src/bin/scripts/po/de.po
M src/bin/scripts/po/sv.po
M src/interfaces/ecpg/ecpglib/nls.mk
M src/interfaces/ecpg/ecpglib/po/de.po
M src/interfaces/ecpg/ecpglib/po/ru.po
M src/interfaces/ecpg/ecpglib/po/sv.po
A src/interfaces/ecpg/ecpglib/po/uk.po
M src/interfaces/ecpg/preproc/nls.mk
M src/interfaces/ecpg/preproc/po/de.po
M src/interfaces/ecpg/preproc/po/ru.po
M src/interfaces/ecpg/preproc/po/sv.po
A src/interfaces/ecpg/preproc/po/uk.po
M src/interfaces/libpq/nls.mk
M src/interfaces/libpq/po/de.po
M src/interfaces/libpq/po/ru.po
M src/interfaces/libpq/po/sv.po
A src/interfaces/libpq/po/uk.po
M src/pl/plperl/po/ru.po
M src/pl/plpgsql/src/nls.mk
M src/pl/plpgsql/src/po/de.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpgsql/src/po/sv.po
A src/pl/plpgsql/src/po/uk.po
M src/pl/plpython/nls.mk
M src/pl/plpython/po/ru.po
A src/pl/plpython/po/uk.po
M src/pl/tcl/nls.mk
M src/pl/tcl/po/de.po
M src/pl/tcl/po/ru.po
A src/pl/tcl/po/uk.po
Improve new AND CHAIN tests
commit : ef48a0573bf0fc5c7e23f077788a055aad9f5e9e
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 9 Sep 2019 10:30:22 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 9 Sep 2019 10:30:22 +0200
Tweak the tests so that we're not just testing the default setting of
transaction_read_only.
Reported-by: fn ln <emuser20140816@gmail.com>
M src/test/regress/expected/transactions.out
M src/test/regress/sql/transactions.sql
Fix RelationIdGetRelation calls that weren't bothering with error checks.
commit : 2403e54fff3b47735fc1a77c51e407c3596d3331
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 8 Sep 2019 17:00:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 8 Sep 2019 17:00:29 -0400
Some of these are quite old, but that doesn't make them not bugs.
We'd rather report a failure via elog than SIGSEGV.
While at it, uniformly spell the error check as !RelationIsValid(rel)
rather than a bare rel == NULL test. The machine code is the same
but it seems better to be consistent.
Coverity complained about this today, not sure why, because the
mistake is in fact old.
M src/backend/replication/logical/reorderbuffer.c
Fix handling of NULL distances in KNN-GiST
commit : e6af7b367cf46fc385307efcef5a1fece0e5fef3
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 8 Sep 2019 21:13:40 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 8 Sep 2019 21:13:40 +0300
In order to implement NULL LAST semantic GiST previously assumed distance to
the NULL value to be Inf. However, our distance functions can return Inf and
NaN for non-null values. In such cases, NULL LAST semantic appears to be
broken. This commit fixes that by introducing separate array of null flags for
distances.
Backpatch to all supported versions.
Discussion: https://postgr.es/m/CAPpHfdsNvNdA0DBS%2BwMpFrgwT6C3-q50sFVGLSiuWnV3FqOJuQ%40mail.gmail.com
Author: Alexander Korotkov
Backpatch-through: 9.4
M src/backend/access/gist/gistget.c
M src/backend/access/gist/gistscan.c
M src/backend/access/index/indexam.c
M src/backend/access/spgist/spgscan.c
M src/include/access/genam.h
M src/include/access/gist_private.h
M src/test/regress/expected/create_index.out
Fix handling Inf and Nan values in GiST pairing heap comparator
commit : bc67f4189a7a3381db76dbfeafca463187bfe87a
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 8 Sep 2019 21:07:30 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 8 Sep 2019 21:07:30 +0300
Previously plain float comparison was used in GiST pairing heap. Such
comparison doesn't provide proper ordering for value sets containing Inf and Nan
values. This commit fixes that by usage of float8_cmp_internal(). Note, there
is remaining problem with NULL distances, which are represented as Inf in
pairing heap. It would be fixes in subsequent commit.
Backpatch to all supported versions.
Reported-by: Andrey Borodin
Discussion: https://postgr.es/m/CAPpHfdsNvNdA0DBS%2BwMpFrgwT6C3-q50sFVGLSiuWnV3FqOJuQ%40mail.gmail.com
Author: Alexander Korotkov
Reviewed-by: Heikki Linnakangas
Backpatch-through: 9.4
M src/backend/access/gist/gistscan.c
M src/test/regress/expected/create_index.out
Fix behavior of AND CHAIN outside of explicit transaction blocks
commit : b6d72ddd5fbf3f6eb79597ab0c8ec3aaa7c16805
author : Peter Eisentraut <peter@eisentraut.org>
date : Sun, 8 Sep 2019 16:11:21 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sun, 8 Sep 2019 16:11:21 +0200
When using COMMIT AND CHAIN or ROLLBACK AND CHAIN not in an explicit
transaction block, the previous implementation would leave a
transaction block active in the ROLLBACK case but not the COMMIT case.
To fix for now, error out when using these commands not in an explicit
transaction block. This restriction could be lifted if a sensible
definition and implementation is found.
Bug: #15977
Author: fn ln <emuser20140816@gmail.com>
Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr>
M doc/src/sgml/ref/commit.sgml
M doc/src/sgml/ref/rollback.sgml
M src/backend/access/transam/xact.c
M src/test/regress/expected/transactions.out
M src/test/regress/sql/transactions.sql
doc: effective -> efficient
commit : 422910423b6cba6abc3790b8f20854c9e78e04a4
author : Peter Eisentraut <peter@eisentraut.org>
date : Sun, 8 Sep 2019 11:10:49 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sun, 8 Sep 2019 11:10:49 +0200
M doc/src/sgml/json.sgml
doc: Clean up title case use
commit : eecd7c3d2b44094d00e967c7283fc2236d8def5d
author : Peter Eisentraut <peter@eisentraut.org>
date : Sun, 8 Sep 2019 10:26:35 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sun, 8 Sep 2019 10:26:35 +0200
Note: Following existing practice, titles of formalpara and step are
not titlecased.
M doc/src/sgml/amcheck.sgml
M doc/src/sgml/arch-dev.sgml
M doc/src/sgml/backup.sgml
M doc/src/sgml/charset.sgml
M doc/src/sgml/config.sgml
M doc/src/sgml/custom-scan.sgml
M doc/src/sgml/dfunc.sgml
M doc/src/sgml/docguide.sgml
M doc/src/sgml/earthdistance.sgml
M doc/src/sgml/ecpg.sgml
M doc/src/sgml/extend.sgml
M doc/src/sgml/fdwhandler.sgml
M doc/src/sgml/features.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/gist.sgml
M doc/src/sgml/high-availability.sgml
M doc/src/sgml/install-windows.sgml
M doc/src/sgml/installation.sgml
M doc/src/sgml/intro.sgml
M doc/src/sgml/jit.sgml
M doc/src/sgml/json.sgml
M doc/src/sgml/libpq.sgml
M doc/src/sgml/limits.sgml
M doc/src/sgml/lobj.sgml
M doc/src/sgml/maintenance.sgml
M doc/src/sgml/monitoring.sgml
M doc/src/sgml/mvcc.sgml
M doc/src/sgml/nls.sgml
M doc/src/sgml/pageinspect.sgml
M doc/src/sgml/perform.sgml
M doc/src/sgml/planstats.sgml
M doc/src/sgml/plhandler.sgml
M doc/src/sgml/plpgsql.sgml
M doc/src/sgml/plpython.sgml
M doc/src/sgml/protocol.sgml
M doc/src/sgml/ref/create_table.sgml
M doc/src/sgml/ref/pg_rewind.sgml
M doc/src/sgml/ref/pgbench.sgml
M doc/src/sgml/ref/pgtesttiming.sgml
M doc/src/sgml/ref/pgupgrade.sgml
M doc/src/sgml/ref/postgres-ref.sgml
M doc/src/sgml/runtime.sgml
M doc/src/sgml/sourcerepo.sgml
M doc/src/sgml/spgist.sgml
M doc/src/sgml/storage.sgml
M doc/src/sgml/syntax.sgml
M doc/src/sgml/tablesample-method.sgml
M doc/src/sgml/xaggr.sgml
M doc/src/sgml/xfunc.sgml
M doc/src/sgml/xindex.sgml
M doc/src/sgml/xoper.sgml
M doc/src/sgml/xtypes.sgml
Avoid using INFO elevel for what are fundamentally debug messages.
commit : 121e3ceed6d93c2891208005f0b270ee80dc13e7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 7 Sep 2019 19:03:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 7 Sep 2019 19:03:11 -0400
Commit 6f6b99d13 stuck an INFO message into the fast path for
checking partition constraints, for no very good reason except
that it made it easy for the regression tests to verify that
that path was taken. Assorted later patches did likewise,
increasing the unsuppressable-chatter level from ALTER TABLE
even more. This isn't good for the user experience, so let's
drop these messages down to DEBUG1 where they belong. So as
not to have a loss of test coverage, create a TAP test that
runs the relevant queries with client_min_messages = DEBUG1
and greps for the expected messages.
This testing method is a bit brute-force --- in particular,
it duplicates the execution of a fair amount of the core
create_table and alter_table tests. We experimented with
other solutions, but running any significant amount of
standard testing with client_min_messages = DEBUG1 seems
to have a lot of output-stability pitfalls, cf commits
bbb96c370 and 5655565c0. Possibly at some point we'll look
into whether we can reduce the amount of test duplication.
Backpatch into v12, because some of these messages are new
in v12 and we don't really want to ship it that way.
Sergei Kornilov
Discussion: https://postgr.es/m/81911511895540@web58j.yandex.ru
Discussion: https://postgr.es/m/4859321552643736@myt5-02b80404fd9e.qloud-c.yandex.net
M src/backend/commands/tablecmds.c
M src/backend/partitioning/partbounds.c
M src/test/modules/Makefile
A src/test/modules/test_misc/.gitignore
A src/test/modules/test_misc/Makefile
A src/test/modules/test_misc/README
A src/test/modules/test_misc/t/001_constraint_validation.pl
M src/test/regress/expected/alter_table.out
M src/test/regress/expected/create_table.out
M src/tools/msvc/Mkvcbuild.pm
Doc: make an editing pass over the v12 release notes.
commit : b6a4d0498757a6e345e07b2a84eb8333f5e5235e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 7 Sep 2019 11:21:24 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 7 Sep 2019 11:21:24 -0400
Copy-edit or rewrite some items, add some items that I thought
deserved documenting, remove some others that didn't (notably,
I'm not on board with documenting documentation changes), fix
some poorly-pointed links, move some items to other sections,
etc etc.
M doc/src/sgml/release-12.sgml
Message style fixes
commit : 2552c78c18a1cb11d0f49a3af0660a477f81839d
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 6 Sep 2019 16:12:28 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 6 Sep 2019 16:12:28 +0200
M src/bin/psql/command.c
M src/bin/psql/help.c
M src/interfaces/ecpg/ecpglib/error.c
M src/interfaces/ecpg/ecpglib/prepare.c
M src/interfaces/ecpg/preproc/ecpg.trailer
M src/interfaces/ecpg/test/expected/sql-declare.stderr
M src/interfaces/libpq/fe-connect.c
doc: Fix awkward markup
commit : ce35a265a438813cd337307b6997a58ac87bf9c9
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 6 Sep 2019 22:19:53 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 6 Sep 2019 22:19:53 +0200
M doc/src/sgml/ref/pg_dumpall.sgml
doc: Postgres -> PostgreSQL
commit : 69116b743af01bd0ab87b5dfc7395029002e23a1
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 6 Sep 2019 22:16:58 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 6 Sep 2019 22:16:58 +0200
M doc/src/sgml/bki.sgml
M doc/src/sgml/installation.sgml
Update v12 release notes through today, and add major-enhancements list.
commit : 700a1ac073730eca8b2d2235ced133f563a26a1b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 6 Sep 2019 15:15:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 6 Sep 2019 15:15:38 -0400
I still want to review the rest of the notes, but this seems like the
minimum work required to prepare for beta4.
Major-enhancements text, and a couple of other fixes, from Jonathan Katz
(with minor copy-editing by me).
M doc/src/sgml/release-12.sgml
Doc: tweak installation doc edits made by commit 76c2af926.
commit : d1da0bc92c3124de44fca5989ed4506a30bb1a6a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 6 Sep 2019 11:24:36 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 6 Sep 2019 11:24:36 -0400
We don't consider that building with MinGW is deprecated,
so adjust some places that gave that impression.
Per discussion with Peter Eisentraut.
Discussion: https://postgr.es/m/4a023388-8652-fea0-a0b4-35ad5e734e9a@2ndquadrant.com
M doc/src/sgml/installation.sgml
M doc/src/sgml/standalone-install.xml
When performing a base backup, check for read errors.
commit : ce5542d4025321273d7d0915fb76977937da6994
author : Robert Haas <rhaas@postgresql.org>
date : Fri, 6 Sep 2019 08:22:32 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Fri, 6 Sep 2019 08:22:32 -0400
The old code didn't differentiate between a read error and a
concurrent truncation. fread reports both of these by returning 0;
you have to use feof() or ferror() to distinguish between them,
which this code did not do.
It might be a better idea to use read() rather than fread() here,
so that we can display a less-generic error message, but I'm not
sure that would qualify as a back-patchable bug fix, so just do
this much for now.
Jeevan Chalke, reviewed by Jeevan Ladhe and by me.
Discussion: http://postgr.es/m/CA+TgmobG4ywMzL5oQq2a8YKp8x2p3p1LOMMcGqpS7aekT9+ETA@mail.gmail.com
M src/backend/replication/basebackup.c
libpq: ccache -> credential cache
commit : d57a931a85dff67fb7447da5f252bb9a9ecbb6d9
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 6 Sep 2019 09:15:35 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 6 Sep 2019 09:15:35 +0200
The term "ccache" is overloaded. Let's be more clear, in case someone
other than a Kerberos wizard has to read this code.
M src/interfaces/libpq/fe-connect.c
M src/interfaces/libpq/fe-gssapi-common.c
M src/interfaces/libpq/fe-gssapi-common.h
Make pg_promote() detect postmaster death while waiting for promotion to end.
commit : 7aa815a7aadd0dcc0515dfc3a88677deb0ca11ff
author : Fujii Masao <fujii@postgresql.org>
date : Fri, 6 Sep 2019 14:27:25 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Fri, 6 Sep 2019 14:27:25 +0900
Previously even if postmaster died and WaitLatch() woke up with that event
while pg_promote() was waiting for the standby promotion to finish,
pg_promote() did nothing special and kept waiting until timeout occurred.
This could cause a busy loop.
This patch make pg_promote() return false immediately when postmaster
dies, to avoid such a busy loop.
Back-patch to v12 where pg_promote() was added.
Author: Fujii Masao
Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/CAHGQGwEs9ROgSp+QF+YdDU+xP8W=CY1k-_Ov-d_Z3JY+to3eXA@mail.gmail.com
M src/backend/access/transam/xlogfuncs.c
Fix thinko when ending progress report for a backend
commit : 4c3e750ab4b5f1900abfa7000aad5e6322f47b5d
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 4 Sep 2019 15:46:45 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 4 Sep 2019 15:46:45 +0900
The logic ending progress reporting for a backend entry introduced by
b6fb647 causes callers of pgstat_progress_end_command() to do some extra
work when track_activities is enabled as the process fields are reset in
the backend entry even if no command were started for reporting.
This resets the fields only if a command is registered for progress
reporting, and only if track_activities is enabled.
Author: Masahiho Sawada
Discussion: https://postgr.es/m/CAD21AoCry_vJ0E-m5oxJXGL3pnos-xYGCzF95rK5Bbi3Uf-rpA@mail.gmail.com
Backpatch-through: 9.6
M src/backend/postmaster/pgstat.c
Delay fsyncs of pg_basebackup until the end of backup
commit : 64eb426afc344600d7d4b9944ed7c3be7ed1812d
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 4 Sep 2019 13:23:41 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 4 Sep 2019 13:23:41 +0900
Since the addition of fsync requests in bc34223 to make base backup data
consistent on disk once pg_basebackup finishes, each tablespace tar file
is individually flushed once completed, with an additional flush of the
parent directory when the base backup finishes. While holding a
connection to the server, a fsync request taking a long time may cause a
failure of the base backup, which is annoying for any integration. A
recent example of breakage can involve tcp_user_timeout, but
wal_sender_timeout can cause similar problems.
While reviewing the code, there was a second issue causing too many
fsync requests to be done for the same WAL data. As recursive fsyncs
are done at the end of the backup for both the plain and tar formats
from the base target directory where everything is written, it is fine
to disable fsyncs when fetching or streaming WAL.
Reported-by: Ryohei Takahashi
Author: Michael Paquier
Reviewed-by: Ryohei Takahashi
Discussion: https://postgr.es/m/OSBPR01MB4550DAE2F8C9502894A45AAB82BE0@OSBPR01MB4550.jpnprd01.prod.outlook.com
Backpatch-through: 10
M src/bin/pg_basebackup/pg_basebackup.c
Clarify pg_dump documentation
commit : 73687190d1e750b4ff94dd0213af7f5f4d3026a7
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 3 Sep 2019 14:25:26 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 3 Sep 2019 14:25:26 +0200
Clarify in the help output and documentation that -n, -t etc. take a
"pattern" rather than a "schema" or "table" etc. This was especially
confusing now that the new pg_dumpall --exclude-database option was
documented with "pattern" and the others not, even though they all
behave the same.
Discussion: https://www.postgresql.org/message-id/flat/b85f3fa1-b350-38d1-1893-4f7911bd7310%402ndquadrant.com
M doc/src/sgml/ref/pg_dump.sgml
M src/bin/pg_dump/pg_dump.c
pg_checksums: Handle read and write returns correctly
commit : 3e20b7fa408f1b5a1bf17120b55b5473e82a7e63
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 3 Sep 2019 08:26:55 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 3 Sep 2019 08:26:55 +0200
The read() return was not checking for errors, the write() return was
not checking for short writes.
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://www.postgresql.org/message-id/flat/5de61b6b-8be9-7771-0048-860328efe027%402ndquadrant.com
M src/bin/pg_checksums/pg_checksums.c
Better error messages for short reads/writes in SLRU
commit : 6ef121647f7f29b59b86eca3dee9b90548245a3a
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 3 Sep 2019 08:26:55 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 3 Sep 2019 08:26:55 +0200
This avoids getting a
Could not read from file ...: Success.
for a short read or write (since errno is not set in that case).
Instead, report a more specific error messages.
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://www.postgresql.org/message-id/flat/5de61b6b-8be9-7771-0048-860328efe027%402ndquadrant.com
M src/backend/access/transam/slru.c
Fix memory leak with lower, upper and initcap with ICU-provided collations
commit : 5380719f931a101a6e83efc7a1664e42bd6bf6c3
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 3 Sep 2019 12:31:03 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 3 Sep 2019 12:31:03 +0900
The leak happens in str_tolower, str_toupper and str_initcap, which are
used in several places including their equivalent SQL-level functions,
and can only be triggered when using an ICU-provided collation when
converting the input string.
b615920 fixed a similar leak. Backpatch down 10 where ICU collations
have been introduced.
Author: Konstantin Knizhnik
Discussion: https://postgr.es/m/94c0ad0a-cbc2-e4a3-7829-2bdeaf9146db@postgrespro.ru
Backpatch-through: 10
M src/backend/utils/adt/formatting.c
Avoid touching replica identity index in ExtractReplicaIdentity().
commit : aad0926ebbe96fbbc3c963b58f2abbcf81895a06
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Sep 2019 16:10:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Sep 2019 16:10:37 -0400
In what seems like a fit of misplaced optimization,
ExtractReplicaIdentity() accessed the relation's replica-identity
index without taking any lock on it. Usually, the surrounding query
already holds some lock so this is safe enough ... but in the case
of a previously-planned delete, there might be no existing lock.
Given a suitable test case, this is exposed in v12 and HEAD by an
assertion added by commit b04aeb0a0.
The whole thing's rather poorly thought out anyway; rather than
looking directly at the index, we should use the index-attributes
bitmap that's held by the parent table's relcache entry, as the
caller functions do. This is more consistent and likely a bit
faster, since it avoids a cache lookup. Hence, change to doing it
that way.
While at it, rather than blithely assuming that the identity
columns are non-null (with catastrophic results if that's wrong),
add assertion checks that they aren't null. Possibly those should
be actual test-and-elog, but I'll leave it like this for now.
In principle, this is a bug that's been there since this code was
introduced (in 9.4). In practice, the risk seems quite low, since
we do have a lock on the index's parent table, so concurrent
changes to the index's catalog entries seem unlikely. Given the
precedent that commit 9c703c169 wasn't back-patched, I won't risk
back-patching this further than v12.
Per report from Hadi Moshayedi.
Discussion: https://postgr.es/m/CAK=1=Wrek44Ese1V7LjKiQS-Nd-5LgLi_5_CskGbpggKEf3tKQ@mail.gmail.com
M src/backend/access/heap/heapam.c
Handle corner cases correctly in psql's reconnection logic.
commit : 90433c38ec5a2c3da576d9526370bcc3057ee9fb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Sep 2019 14:02:45 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 2 Sep 2019 14:02:45 -0400
After an unexpected connection loss and successful reconnection,
psql neglected to resynchronize its internal state about the server,
such as server version. Ordinarily we'd be reconnecting to the same
server and so this isn't really necessary, but there are scenarios
where we do need to update --- one example is where we have a list
of possible connection targets and they're not all alike.
Define "resynchronize" as including connection_warnings(), so that
this case acts the same as \connect. This seems useful; for example,
if the server version did change, the user might wish to know that.
An attuned user might also notice that the new connection isn't
SSL-encrypted, for example, though this approach isn't especially
in-your-face about such changes. Although this part is a behavioral
change, it only affects interactive sessions, so it should not break
any applications.
Also, in do_connect, make sure that we desynchronize correctly when
abandoning an old connection in non-interactive mode.
These problems evidently are the result of people patching only one
of the two places where psql deals with connection changes, so insert
some cross-referencing comments in hopes of forestalling future bugs
of the same ilk.
Lastly, in Windows builds, issue codepage mismatch warnings only at
startup, not during reconnections. psql's codepage can't change
during a reconnect, so complaining about it again seems like useless
noise.
Peter Billen and Tom Lane. Back-patch to all supported branches.
Discussion: https://postgr.es/m/CAMTXbE8e6U=EBQfNSe01Ej17CBStGiudMAGSOPaw-ALxM-5jXg@mail.gmail.com
M src/bin/psql/command.c
M src/bin/psql/common.c
Doc: describe the "options" allowed in an ECPG connection target string.
commit : 5eec908c3c2e2d328e0b1bee76881f0d63cedd1f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 31 Aug 2019 14:05:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 31 Aug 2019 14:05:32 -0400
These have been there a long time, but their format was never explained
in the docs. Per complaint from Yusuke Egashira.
Discussion: https://postgr.es/m/848B1649C8A6274AA527C4472CA11EDD5FC70CBE@G01JPEXMBYT02
M doc/src/sgml/ecpg.sgml
Doc: remove some long-obsolete information from installation.sgml.
commit : 359209835223db95fa589064d8f7548e17da287c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 30 Aug 2019 13:02:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 30 Aug 2019 13:02:35 -0400
Section 16.2 pointed to platform-specific FAQ files that we removed
way back in 8.4. Section 16.7 contained a bunch of information about
AIX and HPUX bugs that were squashed decades ago, plus discussions of
old compiler versions that are certainly moot now that we require C99
support. Since we're obviously not maintaining this stuff carefully,
just remove it. The HPUX sub-section seems like it can go away
entirely, since everything it said that was still applicable was
redundant with material elsewhere in the chapter.
In passing, I couldn't resist the temptation to do a small amount
of copy-editing on nearby text.
Back-patch to v12, since this stuff is surely obsolete in any
branch that requires C99.
Discussion: https://postgr.es/m/15538.1567042743@sss.pgh.pa.us
M doc/src/sgml/installation.sgml
Fix typos in regression test comments.
commit : 8ff5de1c7aa2439ae69f53efd61390026505aee4
author : Etsuro Fujita <efujita@postgresql.org>
date : Thu, 29 Aug 2019 18:45:01 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Thu, 29 Aug 2019 18:45:01 +0900
M src/test/regress/expected/partition_join.out
M src/test/regress/sql/partition_join.sql
Fix overflow check and comment in GIN posting list encoding.
commit : 6b7819a0bd01ebe4ede13bf84dbd51b524eb128a
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 28 Aug 2019 12:55:33 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 28 Aug 2019 12:55:33 +0300
The comment did not match what the code actually did for integers with
the 43rd bit set. You get an integer like that, if you have a posting
list with two adjacent TIDs that are more than 2^31 blocks apart.
According to the comment, we would store that in 6 bytes, with no
continuation bit on the 6th byte, but in reality, the code encodes it
using 7 bytes, with a continuation bit on the 6th byte as normal.
The decoding routine also handled these 7-byte integers correctly, except
for an overflow check that assumed that one integer needs at most 6 bytes.
Fix the overflow check, and fix the comment to match what the code
actually does. Also fix the comment that claimed that there are 17 unused
bits in the 64-bit representation of an item pointer. In reality, there
are 64-32-11=21.
Fitting any item pointer into max 6 bytes was an important property when
this was written, because in the old pre-9.4 format, item pointers were
stored as plain arrays, with 6 bytes for every item pointer. The maximum
of 6 bytes per integer in the new format guaranteed that we could convert
any page from the old format to the new format after upgrade, so that the
new format was never larger than the old format. But we hardly need to
worry about that anymore, and running into that problem during upgrade,
where an item pointer is expanded from 6 to 7 bytes such that the data
doesn't fit on a page anymore, is implausible in practice anyway.
Backpatch to all supported versions.
This also includes a little test module to test these large distances
between item pointers, without requiring a 16 TB table. It is not
backpatched, I'm including it more for the benefit of future development
of new posting list formats.
Discussion: https://www.postgresql.org/message-id/33bfc20a-5c86-f50c-f5a5-58e9925d05ff%40iki.fi
Reviewed-by: Masahiko Sawada, Alexander Korotkov
M src/backend/access/gin/ginpostinglist.c
Avoid catalog lookups in RelationAllowsEarlyPruning().
commit : 8cc6016a8cd43f84998f57e277a988be651e2e6d
author : Thomas Munro <tmunro@postgresql.org>
date : Wed, 28 Aug 2019 13:37:03 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Wed, 28 Aug 2019 13:37:03 +1200
RelationAllowsEarlyPruning() performed a catalog scan, but is used
in two contexts where that was a bad idea:
1. In heap_page_prune_opt(), which runs very frequently in some large
scans. This caused major performance problems in a field report
that was easy to reproduce.
2. In TestForOldSnapshot(), which runs while we hold a buffer content
lock. It's not clear if this was guaranteed to be free of buffer
deadlock risk.
The check was introduced in commit 2cc41acd8 and defended against a
real problem: 9.6's hash indexes have no page LSN and so we can't
allow early pruning (ie the snapshot-too-old feature). We can remove
the check from all later releases though: hash indexes are now logged,
and there is no way to create UNLOGGED indexes on regular logged
tables.
If a future release allows such a combination, it might need to put
a similar check in place, but it'll need some more thought.
Back-patch to 10.
Author: Thomas Munro
Reviewed-by: Tom Lane, who spotted the second problem
Discussion: https://postgr.es/m/CA%2BhUKGKT8oTkp5jw_U4p0S-7UG9zsvtw_M47Y285bER6a2gD%2Bg%40mail.gmail.com
Discussion: https://postgr.es/m/CAA4eK1%2BWy%2BN4eE5zPm765h68LrkWc3Biu_8rzzi%2BOYX4j%2BiHRw%40mail.gmail.com
M src/backend/utils/cache/relcache.c
M src/include/utils/rel.h
M src/include/utils/snapmgr.h
Disable timeouts when running pg_rewind with online source cluster
commit : e96f524433dbc562d708c4d09d8455b6bc953613
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 28 Aug 2019 11:48:15 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 28 Aug 2019 11:48:15 +0900
In this case, the transfer uses a libpq connection, which is subject to
the timeout parameters set at system level, and this can make the rewind
operation suddenly canceled which is not good for automation. One
workaround to such issues would be to use PGOPTIONS to enforce the
wanted timeout parameters, but that's annoying, and for example pg_dump,
which can run potentially long-running queries disables all types of
timeouts.
lock_timeout and statement_timeout are the ones which can cause problems
now. Note that pg_rewind does not use transactions, so disabling
idle_in_transaction_session_timeout is optional, but it feels safer to
do so for the future.
This is back-patched down to 9.5. idle_in_transaction_session_timeout
is only present since 9.6.
Author: Alexander Kukushkin
Discussion: https://postgr.es/m/CAFh8B=krcVXksxiwVQh1SoY+ziJ-JC=6FcuoBL3yce_40Es5_g@mail.gmail.com
Backpatch-through: 9.5
M src/bin/pg_rewind/libpq_fetch.c
Doc: improve documentation of pg_signal_backend default role.
commit : 11f6271b87fab08eea23a31ceaa6b14cdc2e8a6c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 27 Aug 2019 18:03:09 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 27 Aug 2019 18:03:09 -0400
Give it an explanatory para like the other default roles have.
Don't imply that it can send any signal whatever.
In passing, reorder the table entries and explanatory paras
for the default roles into some semblance of consistency.
Ian Barwick, tweaked a bit by me.
Discussion: https://postgr.es/m/89907e32-76f3-7282-a89c-ea19c722fe5d@2ndquadrant.com
M doc/src/sgml/user-manag.sgml
Improve what pg_strsignal prints if we haven't got strsignal(3).
commit : 7570df0f3b6d873cd060b3271b5f7b90cbcfb66c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 27 Aug 2019 17:24:13 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 27 Aug 2019 17:24:13 -0400
Turns out that returning "unrecognized signal" is confusing.
Make it explicit that the platform lacks any support for signal names.
(At least of the machines in the buildfarm, only HPUX lacks it.)
Back-patch to v12 where we invented this function.
Discussion: https://postgr.es/m/3067.1566870481@sss.pgh.pa.us
M src/port/pgstrsignal.c
Doc: clarify behavior of standard aggregates for null inputs.
commit : c0222c2c9b8145a0ccbee7d801db848e871f2e14
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 27 Aug 2019 16:37:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 27 Aug 2019 16:37:22 -0400
Section 4.2.7 says that unless otherwise specified, built-in
aggregates ignore rows in which any input is null. This is
not true of the JSON aggregates, but it wasn't documented.
Fix that.
Of the other entries in table 9.55, some were explicit about
ignoring nulls, and some weren't; for consistency and
self-contained-ness, make them all say it explicitly.
Per bug #15884 from Tim Möhlmann. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/15884-c32d848f787fcae3@postgresql.org
M doc/src/sgml/func.sgml
Reject empty names and recursion in config-file include directives.
commit : 1510339dce3c70757a87be3880e102e0511bf288
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 27 Aug 2019 14:44:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 27 Aug 2019 14:44:26 -0400
An empty file name or subdirectory name leads join_path_components() to
just produce the parent directory name, which leads to weird failures or
recursive inclusions. Let's throw a specific error for that. It takes
only slightly more code to detect all-blank names, so do so.
Also, detect direct recursion, ie a file calling itself. As coded
this will also detect recursion via "include_dir '.'", which is
perhaps more likely than explicitly including the file itself.
Detecting indirect recursion would require API changes for guc-file.l
functions, which seems not worth it since extensions might call them.
The nesting depth limit will catch such cases eventually, just not
with such an on-point error message.
In passing, adjust the example usages in postgresql.conf.sample
to perhaps eliminate the problem at the source: there's no reason
for the examples to suggest that an empty value is valid.
Per a trouble report from Brent Bates. Back-patch to 9.5; the
issue is old, but the code in 9.4 is enough different that the
patch doesn't apply easily, and it doesn't seem worth the trouble
to fix there.
Ian Barwick and Tom Lane
Discussion: https://postgr.es/m/8c8bcbca-3bd9-dc6e-8986-04a5abdef142@2ndquadrant.com
M src/backend/utils/misc/guc-file.l
M src/backend/utils/misc/postgresql.conf.sample
Fix failure of --jobs with vacuumdb on Windows
commit : b783a38d4580d807210e26c2c09eb77b66d7286f
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 27 Aug 2019 09:11:38 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 27 Aug 2019 09:11:38 +0900
FD_SETSIZE needs to be declared before winsock2.h, or it is possible to
run into buffer overflow issues when using --jobs. This is similar to
pgbench's solution done in a23c641.
This has been introduced by 71d84ef, and older versions have been using
the default value of FD_SETSIZE, defined at 64.
Per buildfarm member jacana, but this impacts all Windows animals
running the TAP tests. I have reproduced the failure locally to check
the patch.
Author: Michael Paquier
Reviewed-by: Andrew Dunstan
Discussion: https://postgr.es/m/20190826054000.GE7005@paquier.xyz
Backpatch-through: 9.5
M src/bin/scripts/vacuumdb.c
Fix gettext triggers specification
commit : 6bdd9fb003e26201c4ae6293a9f3b239140b6598
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 26 Aug 2019 19:04:35 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 26 Aug 2019 19:04:35 +0200
In cc8d41511721d25d557fc02a46c053c0a602fed0, the arguments of
warn_or_exit_horribly() were changed but this was not updated.
M src/bin/pg_dump/nls.mk
Adjust to latest Msys2 kernel release number
commit : 97205d04e79ded73ba7fe0196f7817f89a405303
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 26 Aug 2019 08:11:27 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 26 Aug 2019 08:11:27 -0400
Previously 'uname -r' on Msys2 reported a kernele release starting with
2. The latest version starts with 3. In commit 1638623f we specifically
looked for one starting with 2. This is now changed to look for any
digit between 2 and 9.
backpatch to release 10.
M src/bin/pg_dump/t/010_dump_connstr.pl
Treat MINGW and MSYS the same in pg_upgrade test script
commit : 67d5af3f42b72270b0c5a2c36c1f378ab908671a
author : Andrew Dunstan <andrew@dunslane.net>
date : Mon, 26 Aug 2019 07:44:34 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Mon, 26 Aug 2019 07:44:34 -0400
On msys2, 'uname -s' reports a string starting MSYS instead on MINGW
as happens on msys1. Treat these both the same way. This reverts
608a710195a4b in favor of a more general solution.
Backpatch to all live branches.
M src/bin/pg_upgrade/test.sh
Fix error handling of vacuumdb when running out of fds
commit : 63fc3b124008fa626b9f2e57f2211b9c3fb9a4ba
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 26 Aug 2019 11:14:24 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 26 Aug 2019 11:14:24 +0900
When trying to use a high number of jobs, vacuumdb has only checked for
a maximum number of jobs used, causing confusing failures when running
out of file descriptors when the jobs open connections to Postgres.
This commit changes the error handling so as we do not check anymore for
a maximum number of allowed jobs when parsing the option value with
FD_SETSIZE, but check instead if a file descriptor is within the
supported range when opening the connections for the jobs so as this is
detected at the earliest time possible.
Also, improve the error message to give a hint about the number of jobs
recommended, using a wording given by the reviewers of the patch.
Reported-by: Andres Freund
Author: Michael Paquier
Reviewed-by: Andres Freund, Álvaro Herrera, Tom Lane
Discussion: https://postgr.es/m/20190818001858.ho3ev4z57fqhs7a5@alap3.anarazel.de
Backpatch-through: 9.5
M src/bin/scripts/vacuumdb.c
Avoid platform-specific null pointer dereference in psql.
commit : 363382521eb26106587c7dab7f439636c3a6876a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 25 Aug 2019 15:04:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 25 Aug 2019 15:04:04 -0400
POSIX permits getopt() to advance optind beyond argc when the last
argv entry is an option that requires an argument and hasn't got one.
It seems that no major platforms actually do that, but musl does,
so that something like "psql -f" would crash with that libc.
Add a check that optind is in range before trying to look at the
possibly-bogus option.
Report and fix by Quentin Rameau. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/20190825100617.GA6087@fifth.space
M src/bin/psql/startup.c
Back off output precision in circle.sql regression test.
commit : cd714b3507c914e78d47352d1e126b4bec4380ad
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 25 Aug 2019 12:14:50 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 25 Aug 2019 12:14:50 -0400
We were setting extra_float_digits = 0 to avoid platform-dependent
output in this test, but that's still able to expose platform-specific
roundoff behavior in some new test cases added by commit a3d284485,
as reported by Peter Eisentraut. Reduce it to -1 to hide that.
(Over in geometry.sql, we're using -3, which is an ancient decision
dating to 337f73b1b. I wonder whether that's overkill now. But
there's probably little value in trying to change it.)
Back-patch to v12 where a3d284485 came in; there's no evidence that
we have any platform-dependent issues here before that.
Discussion: https://postgr.es/m/15551268-e224-aa46-084a-124b64095ee3@2ndquadrant.com
M src/test/regress/expected/circle.out
M src/test/regress/sql/circle.sql
Don't rely on llvm::make_unique.
commit : 54ff1c34f11b3f899be66fa55f85dbace83be741
author : Thomas Munro <tmunro@postgresql.org>
date : Sun, 25 Aug 2019 13:54:48 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Sun, 25 Aug 2019 13:54:48 +1200
Bleeding-edge LLVM has stopped supplying replacements for various
C++14 library features, for people on older C++ versions. Since we're
not ready to require C++14 yet, just use plain old new instead of
make_unique. As revealed by buildfarm animal seawasp.
Back-patch to 11.
Reviewed-by: Andres Freund
Discussion: https://postgr.es/m/CA%2BhUKGJWG7unNqmkxg7nC5o3o-0p2XP6co4r%3D9epqYMm8UY4Mw%40mail.gmail.com
M src/backend/jit/llvm/llvmjit_inline.cpp
Improve documentation of pageinspect
commit : 08e68825c1d6cc87606e592a8080fece5da3fd31
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 23 Aug 2019 20:41:13 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 23 Aug 2019 20:41:13 +0900
This adds a section for heap-related functions. These were previously
mixed with functions having a more general purpose, leading to
confusion. While on it, add a query example for fsm_page_contents.
Backpatch down to 10, where b5e3942 introduced the subsections for
function types in pageinspect documentation.
Author: Masahiko Sawada
Discussion: https://postgr.es/m/CAD21AoDyM7E1+cK3-aWejxKTGC-wVVP2B+RnJhN6inXyeRmqzw@mail.gmail.com
Backpatch-through: 10
M doc/src/sgml/pageinspect.sgml
doc: PG 12 relnotes, correct pg_stat_database.datoid to be datid
commit : ea4aa9801f9cb9f42255657c387e7594d6717cf8
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 22 Aug 2019 20:19:20 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 22 Aug 2019 20:19:20 -0400
Previous column name was incorrect.
Reported-by: Justin Pryzby
Backpatch-through: 12
M doc/src/sgml/release-12.sgml
Fixes for "Glyph not available" warnings from FOP
commit : 73ebfb10d0410af6b95a288f48b9fae3648bd3c7
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 22 Aug 2019 22:36:45 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 22 Aug 2019 22:36:45 +0200
see d315639c82e8a2cfd1d1b98b7acf0f6c033ab955
M doc/src/sgml/release-12.sgml
Add list of acknowledgments to release notes
commit : f87b986e7d9fb47bd7dae77c26a79698d5297ab5
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 22 Aug 2019 22:35:00 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 22 Aug 2019 22:35:00 +0200
This contains all individuals mentioned in the commit messages during
PostgreSQL 12 development.
current through 068bc300c6ed5333d9561e55cb5f45d17de88422
M doc/src/sgml/release-12.sgml
Make SQL/JSON error code names match SQL standard
commit : 04f576a999e052187c3ff3bac4965fcd63b34820
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 22 Aug 2019 10:17:30 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 22 Aug 2019 10:17:30 +0200
There were some minor differences that didn't seem necessary.
Discussion: https://www.postgresql.org/message-id/flat/86b67eef-bb26-c97d-3e35-64f1fbd4f9fe%402ndquadrant.com
M src/backend/utils/adt/jsonpath_exec.c
M src/backend/utils/errcodes.txt
Doc: Remove mention to "Visual Studio Express 2019"
commit : 39511da1c0143c246c2c759cbde673a8b2ea404f
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 22 Aug 2019 09:59:16 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 22 Aug 2019 09:59:16 +0900
The "Express" flavor of Visual Studio exists up to 2017, and the
documentation referred to "Express" for Visual Studio 2019.
Author: Takuma Hoshiai
Discussion: https://postgr.es/m/20190820120231.f905542e685140258ca73d82@sraoss.co.jp
Backpatch-through: 9.4
M doc/src/sgml/install-windows.sgml
Fix typo
commit : d60ec8fe529850d10c3422086912056c5af4e61c
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 21 Aug 2019 11:12:44 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 21 Aug 2019 11:12:44 -0400
In early development patches, "replication origins" were called "identifiers";
almost everything was renamed, but these references to the old terminology
went unnoticed.
Reported-by: Craig Ringer
M src/backend/replication/logical/origin.c
M src/include/catalog/pg_proc.dat
Fix bogus comment
commit : 068bc300c6ed5333d9561e55cb5f45d17de88422
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 20 Aug 2019 16:04:09 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 20 Aug 2019 16:04:09 -0400
Author: Alexander Lakhin
Discussion: https://postgr.es/m/20190819072244.GE18166@paquier.xyz
M src/backend/access/heap/heapam.c
Doc: Fix various typos
commit : d38753c6f79d1eb7d3096ff777ec6df0bc7e5008
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 20 Aug 2019 13:45:53 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 20 Aug 2019 13:45:53 +0900
All those fixes are already included on HEAD thanks to for example
c96581a and 66bde49, and have gone missing on back-branches.
Author: Alexander Lakhin, Liudmila Mantrova
Discussion: https://postgr.es/m/CAEkD-mDJHV3bhgezu3MUafJLoAKsOOT86+wHukKU8_NeiJYhLQ@mail.gmail.com
Backpatch-through: 9.4
M doc/src/sgml/catalogs.sgml
M doc/src/sgml/custom-scan.sgml
M doc/src/sgml/ecpg.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/gist.sgml
M doc/src/sgml/libpq.sgml
M doc/src/sgml/plpgsql.sgml
M doc/src/sgml/problems.sgml
M doc/src/sgml/ref/create_aggregate.sgml
M doc/src/sgml/ref/set_role.sgml
M doc/src/sgml/sources.sgml
M doc/src/sgml/sslinfo.sgml
M doc/src/sgml/xplang.sgml
Doc: Improve wording of multiple places in documentation
commit : b298e37013683f896b0a224eee50937730faeca8
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 20 Aug 2019 12:37:30 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 20 Aug 2019 12:37:30 +0900
This has been found during its translation.
Author: Liudmila Mantrova
Discussion: https://postgr.es/m/CAEkD-mDJHV3bhgezu3MUafJLoAKsOOT86+wHukKU8_NeiJYhLQ@mail.gmail.com
Backpatch-through: 12
M doc/src/sgml/catalogs.sgml
M doc/src/sgml/client-auth.sgml
M doc/src/sgml/config.sgml
M doc/src/sgml/ecpg.sgml
M doc/src/sgml/libpq.sgml
M doc/src/sgml/maintenance.sgml
M doc/src/sgml/planstats.sgml
M doc/src/sgml/ref/create_table.sgml
M doc/src/sgml/storage.sgml
Restore json{b}_populate_record{set}'s ability to take type info from AS.
commit : cdc8d371e27d534626b19e0810a8de74a31e2c91
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 19 Aug 2019 18:00:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 19 Aug 2019 18:00:57 -0400
If the record argument is NULL and has no declared type more concrete
than RECORD, we can't extract useful information about the desired
rowtype from it. In this case, see if we're in FROM with an AS clause,
and if so extract the needed rowtype info from AS.
It worked like this before v11, but commit 37a795a60 removed the
behavior, reasoning that it was undocumented, inefficient, and utterly
not self-consistent. If you want to take type info from an AS clause,
you should be using the json_to_record() family of functions not the
json_populate_record() family. Also, it was already the case that
the "populate" functions would fail for a null-valued RECORD input
(with an unfriendly "record type has not been registered" error)
when there wasn't an AS clause at hand, and it wasn't obvious that
that behavior wasn't OK when there was one. However, it emerges
that some people were depending on this to work, and indeed the
rather off-point error message you got if you left off AS encouraged
slapping on AS without switching to the json_to_record() family.
Hence, put back the fallback behavior of looking for AS. While at it,
improve the run-time error you get when there's no place to obtain type
info; we can do a lot better than "record type has not been registered".
(We can't, unfortunately, easily improve the parse-time error message
that leads people down this path in the first place.)
While at it, I refactored the code a bit to avoid duplicating the
same logic in several different places.
Per bug #15940 from Jaroslav Sivy. Back-patch to v11 where the
current coding came in. (The pre-v11 deficiencies in this area
aren't regressions, so we'll leave those branches alone.)
Patch by me, based on preliminary analysis by Dmitry Dolgov.
Discussion: https://postgr.es/m/15940-2ab76dc58ffb85b6@postgresql.org
M src/backend/utils/adt/jsonfuncs.c
M src/test/regress/expected/json.out
M src/test/regress/expected/jsonb.out
M src/test/regress/sql/json.sql
M src/test/regress/sql/jsonb.sql
doc: Fix image use in PDF build with vpath
commit : 842ac79407a1368308beff230d3e83aad6d82b75
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 19 Aug 2019 10:30:47 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 19 Aug 2019 10:30:47 +0200
In a vpath build, we need to point to the source directory to allow
FOP to find the images.
M doc/src/sgml/Makefile
Disallow changing an inherited column's type if not all parents changed.
commit : 328c3f6f96a4d7cdc368264a97d03c9b75ad54ea
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 18 Aug 2019 17:11:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 18 Aug 2019 17:11:57 -0400
If a table inherits from multiple unrelated parents, we must disallow
changing the type of a column inherited from multiple such parents, else
it would be out of step with the other parents. However, it's possible
for the column to ultimately be inherited from just one common ancestor,
in which case a change starting from that ancestor should still be
allowed. (I would not be excited about preserving that option, were
it not that we have regression test cases exercising it already ...)
It's slightly annoying that this patch looks different from the logic
with the same end goal in renameatt(), and more annoying that it
requires an extra syscache lookup to make the test. However, the
recursion logic is quite different in the two functions, and a
back-patched bug fix is no place to be trying to unify them.
Per report from Manuel Rigger. Back-patch to 9.5. The bug exists in
9.4 too (and doubtless much further back); but the way the recursion
is done in 9.4 is a good bit different, so that substantial refactoring
would be needed to fix it in 9.4. I'm disinclined to do that, or risk
introducing new bugs, for a bug that has escaped notice for this long.
Discussion: https://postgr.es/m/CA+u7OA4qogDv9rz1HAb-ADxttXYPqQdUdPY_yd4kCzywNxRQXA@mail.gmail.com
M src/backend/commands/tablecmds.c
M src/test/regress/expected/inherit.out
M src/test/regress/sql/inherit.sql
Add default_table_access_method to postgresql.conf.sample.
commit : 3a5c08aa02677a4fef40de78e88fc95a3d6ac1e0
author : Andres Freund <andres@anarazel.de>
date : Fri, 16 Aug 2019 15:24:22 -0700
committer: Andres Freund <andres@anarazel.de>
date : Fri, 16 Aug 2019 15:24:22 -0700
Reported-By: Heikki Linnakangas
Author: Michael Paquier
Discussion: https://postgr.es/m/d6ffbebb-a0d2-181c-811d-b029b2225ed7@iki.fi
Backpatch: 12-, where pluggable table access methods were introduced
M src/backend/utils/misc/postgresql.conf.sample
Prevent possible double-free when update trigger returns old tuple.
commit : 03813a50efa563f19110013b06e80f08d4f49cf5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 15 Aug 2019 20:04:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 15 Aug 2019 20:04:19 -0400
This is a variant of the problem fixed in commit 25b692568, which
unfortunately we failed to detect at the time. If an update trigger
returns the "old" tuple, as it's entitled to do, then a subsequent
iteration of the loop in ExecBRUpdateTriggers would have "oldtuple"
equal to "trigtuple" and would fail to notice that it shouldn't
free that.
In addition to fixing the code, extend the test case added by
25b692568 so that it covers multiple-trigger-iterations cases.
This problem does not manifest in v12/HEAD, as a result of the
relevant code having been largely rewritten for slotification.
However, include the test case into v12/HEAD anyway, since this
is clearly an area that someone could break again in future.
Per report from Piotr Gabriel Kosinski. Back-patch into all
supported branches, since the bug seems quite old.
Diagnosis and code fix by Thomas Munro, test case by me.
Discussion: https://postgr.es/m/CAFMLSdP0rd7LqC3j-H6Fh51FYSt5A10DDh-3=W4PPc4LLUQ8YQ@mail.gmail.com
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql
Fix plpgsql to re-look-up composite type names at need.
commit : a4504696e1ed04a112d312e0934dd324e90675e7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 15 Aug 2019 15:21:47 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 15 Aug 2019 15:21:47 -0400
Commit 4b93f5799 rearranged things in plpgsql to make it cope better with
composite types changing underneath it intra-session. However, I failed to
consider the case of a composite type being dropped and recreated entirely.
In my defense, the previous coding didn't consider that possibility at all
either --- but it would accidentally work so long as you didn't change the
type's field list, because the built-at-compile-time list of component
variables would then still match the type's new definition. The new
coding, however, occasionally tries to re-look-up the type by OID, and
then fails to find the dropped type.
To fix this, we need to save the TypeName struct, and then redo the type
OID lookup from that. Of course that's expensive, so we don't want to do
it every time we need the type OID. This can be fixed in the same way that
4b93f5799 dealt with changes to composite types' definitions: keep an eye
on the type's typcache entry to see if its tupledesc has been invalidated.
(Perhaps, at some point, this mechanism should be generalized so it can
work for non-composite types too; but for now, plpgsql only tries to
cope with intra-session redefinitions of composites.)
I'm slightly hesitant to back-patch this into v11, because it changes
the contents of struct PLpgSQL_type as well as the signature of
plpgsql_build_datatype(), so in principle it could break code that is
poking into the innards of plpgsql. However, the only popular extension
of that ilk is pldebugger, and it doesn't seem to be affected. Since
this is a regression for people who were relying on the old behavior,
it seems worth taking the small risk of causing compatibility issues.
Per bug #15913 from Daniel Fiori. Back-patch to v11 where 4b93f5799
came in.
Discussion: https://postgr.es/m/15913-a7e112e16dedcffc@postgresql.org
M src/backend/utils/cache/typcache.c
M src/pl/plpgsql/src/expected/plpgsql_record.out
M src/pl/plpgsql/src/pl_comp.c
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpgsql/src/pl_gram.y
M src/pl/plpgsql/src/plpgsql.h
M src/pl/plpgsql/src/sql/plpgsql_record.sql
Doc: improve documentation about postgresql.auto.conf.
commit : 372d6a8918e03f182242b260902dd47e5c5dd6e5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 15 Aug 2019 11:14:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 15 Aug 2019 11:14:26 -0400
Clarify what external tools can do to this file, and add a bit
of detail about what ALTER SYSTEM itself does.
Discussion: https://postgr.es/m/aed6cc9f-98f3-2693-ac81-52bb0052307e@2ndquadrant.com
M doc/src/sgml/config.sgml
Fix ALTER SYSTEM to cope with duplicate entries in postgresql.auto.conf.
commit : 75b2f011f642bbc7fab8352f4bcfb6e3fc494e7a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 14 Aug 2019 15:09:20 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 14 Aug 2019 15:09:20 -0400
ALTER SYSTEM itself normally won't make duplicate entries (although
up till this patch, it was possible to confuse it by writing case
variants of a GUC's name). However, if some external tool has appended
entries to the file, that could result in duplicate entries for a single
GUC name. In such a situation, ALTER SYSTEM did exactly the wrong thing,
because it replaced or removed only the first matching entry, leaving
the later one(s) still there and hence still determining the active value.
This patch fixes that by making ALTER SYSTEM sweep through the file and
remove all matching entries, then (if not ALTER SYSTEM RESET) append the
new setting to the end. This means entries will be in order of last
setting rather than first setting, but that shouldn't hurt anything.
Also, make the comparisons case-insensitive so that the right things
happen if you do, say, ALTER SYSTEM SET "TimeZone" = 'whatever'.
This has been broken since ALTER SYSTEM was invented, so back-patch
to all supported branches.
Ian Barwick, with minor mods by me
Discussion: https://postgr.es/m/aed6cc9f-98f3-2693-ac81-52bb0052307e@2ndquadrant.com
M src/backend/utils/misc/guc.c
Fix random regression failure in test case "collate.icu.utf8"
commit : b626483bd97be374ad827f800171478773ad8282
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 14 Aug 2019 13:38:16 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 14 Aug 2019 13:38:16 +0900
This is a fix similar to 2d7d67cc, where slight plan alteration can
cause a random failure of this regression test because of an incorect
tuple ordering, except that this one involves lookups of pg_type.
Similarly to the other case, add ORDER BY clauses to ensure the output
order.
The failure has been seen at least once on buildfarm member skink.
Reported-by: Thomas Munro
Discussion: https://postgr.es/m/CA+hUKGLjR9ZBvhXcr9b-NSBHPw9aRgbjyzGE+kqLsT4vwX+nkQ@mail.gmail.com
Backpatch-through: 12
M src/test/regress/expected/collate.icu.utf8.out
M src/test/regress/sql/collate.icu.utf8.sql
Un-break pg_dump for pre-8.3 source servers.
commit : 6844adba54f7d96f30f834efc6d9aa1e52e5672d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 13 Aug 2019 16:57:58 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 13 Aug 2019 16:57:58 -0400
Commit 07b39083c inserted an unconditional reference to pg_opfamily,
which of course fails on servers predating that catalog. Fortunately,
the case it's trying to solve can't occur on such old servers (AFAIK).
Hence, just skip the additional code when the source predates 8.3.
Per bug #15955 from sly. Back-patch to all supported branches,
like the previous patch.
Discussion: https://postgr.es/m/15955-1daa2e676e903d87@postgresql.org
M src/bin/pg_dump/pg_dump.c
Fix random regression failure in test case "temp"
commit : 4c0b9cf9e073ca2dc95a75fe983d90fd518864fb
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 13 Aug 2019 10:55:58 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 13 Aug 2019 10:55:58 +0900
This test case could fail because of an incorrect result ordering when
looking up at pg_class entries. This commit adds an ORDER BY to the
culprit query. The cause of the failure was likely caused by a plan
switch. By default, the planner would likely choose an index-only scan
or an index scan, but even a small change in the startup cost could have
caused a bitmap heap scan to be chosen, causing the failure.
While on it, switch some filtering quals to a regular expression as per
an idea of Tom Lane. As previously shaped, the quals would have
selected any relations whose name begins with "temp". And that could
cause failures if another test running in parallel began to use similar
relation names.
Per report from buildfarm member anole, though the failure was very
rare. This test has been introduced by 319a810, so backpatch down to
v10.
Discussion: https://postgr.es/m/20190807132422.GC15695@paquier.xyz
Backpatch-through: 10
M src/test/regress/expected/temp.out
M src/test/regress/sql/temp.sql
amcheck: Skip unlogged relations during recovery.
commit : a05fa2c0e77535470b6ee1029671eb41c612f4ef
author : Peter Geoghegan <pg@bowt.ie>
date : Mon, 12 Aug 2019 15:21:30 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Mon, 12 Aug 2019 15:21:30 -0700
contrib/amcheck failed to consider the possibility that unlogged
relations will not have any main relation fork files when running in hot
standby mode. This led to low-level "can't happen" errors that complain
about the absence of a relfilenode file.
To fix, simply skip verification of unlogged index relations during
recovery. In passing, add a direct check for the presence of a main
fork just before verification proper begins, so that we cleanly verify
the presence of the main relation fork file.
Author: Andrey Borodin, Peter Geoghegan
Reported-By: Andrey Borodin
Diagnosed-By: Andrey Borodin
Discussion: https://postgr.es/m/DA9B33AC-53CB-4643-96D4-7A0BBC037FA1@yandex-team.ru
Backpatch: 10-, where amcheck was introduced.
M contrib/amcheck/verify_nbtree.c
Fix planner's test for case-foldable characters in ILIKE with ICU.
commit : c0c12ce391d89328640dd948b82466c308d85415
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 Aug 2019 13:15:47 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 12 Aug 2019 13:15:47 -0400
As coded, the ICU-collation path in pattern_char_isalpha() failed
to consider regular ASCII letters to be case-varying. This led to
like_fixed_prefix treating too much of an ILIKE pattern as being a
fixed prefix, so that indexscans derived from an ILIKE clause might
miss entries that they should find.
Per bug #15892 from James Inform. This is an oversight in the original
ICU patch (commit eccfef81e), so back-patch to v10 where that came in.
Discussion: https://postgr.es/m/15892-e5d2bea3e8a04a1b@postgresql.org
M src/backend/utils/adt/like_support.c
M src/test/regress/expected/collate.icu.utf8.out
M src/test/regress/sql/collate.icu.utf8.sql
Fix string comparison in jsonpath
commit : de0dc0b758ed7452ceee756d9d620c4393b3cb53
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 12 Aug 2019 06:19:19 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 12 Aug 2019 06:19:19 +0300
Take into account pg_server_to_any() may return input string "as is".
Reported-by: Andrew Dunstan, Thomas Munro
Discussion: https://postgr.es/m/0ed83a33-d900-466a-880a-70ef456c721f%402ndQuadrant.com
Author: Alexander Korotkov, Thomas Munro
Backpatch-through: 12
M src/backend/utils/adt/jsonpath_exec.c
Adjust string comparison in jsonpath
commit : 3218ff5c6aea5841ab547ecca26927716419fe4b
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 11 Aug 2019 22:54:53 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 11 Aug 2019 22:54:53 +0300
We have implemented jsonpath string comparison using default database locale.
However, standard requires us to compare Unicode codepoints. This commit
implements that, but for performance reasons we still use per-byte comparison
for "==" operator. Thus, for consistency other comparison operators do per-byte
comparison if Unicode codepoints appear to be equal.
In some edge cases, when same Unicode codepoints have different binary
representations in database encoding, we diverge standard to achieve better
performance of "==" operator. In future to implement strict standard
conformance, we can do normalization of input JSON strings.
Original patch was written by Nikita Glukhov, rewritten by me.
Reported-by: Markus Winand
Discussion: https://postgr.es/m/8B7FA3B4-328D-43D7-95A8-37B8891B8C78%40winand.at
Author: Nikita Glukhov, Alexander Korotkov
Backpatch-through: 12
M src/backend/utils/adt/jsonpath_exec.c
M src/test/regress/expected/jsonb_jsonpath.out
M src/test/regress/sql/jsonb_jsonpath.sql
Fix "ANALYZE t, t" inside a transaction block.
commit : 6ce0366be2a3f92a46202acaba40be3aa72fa073
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 10 Aug 2019 11:30:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 10 Aug 2019 11:30:11 -0400
This failed with either "tuple already updated by self" or "duplicate
key value violates unique constraint", depending on whether the table
had previously been analyzed or not. The reason is that ANALYZE tried
to insert or update the same pg_statistic rows twice, and there was no
CommandCounterIncrement between. So add one. The same case works fine
outside a transaction block, because then there's a whole transaction
boundary between, as a consequence of the way VACUUM works.
This issue has been latent all along, but the problem was unreachable
before commit 11d8d72c2 added the ability to specify multiple tables
in ANALYZE. We could, perhaps, alternatively fix it by adding code to
de-duplicate the list of VacuumRelations --- but that would add a
lot of overhead to work around dumb commands, so it's not attractive.
Per bug #15946 from Yaroslav Schekin. Back-patch to v11.
(Note: in v11 I also back-patched the test added by commit 23224563d;
otherwise the problem doesn't manifest in the test I added, because
"vactst" is empty when the tests for multiple ANALYZE targets are
reached. That seems like not a very good thing anyway, so I did this
rather than rethinking the choice of test case.)
Discussion: https://postgr.es/m/15946-5c7570a2884a26cf@postgresql.org
M src/backend/commands/vacuum.c
M src/test/regress/expected/vacuum.out
M src/test/regress/sql/vacuum.sql
Fix SIGSEGV in pruning for ScalarArrayOp with constant-null array.
commit : 59d3789294cf6d42325e92486b053f1ee5934eb8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 Aug 2019 13:20:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 9 Aug 2019 13:20:28 -0400
Not much to be said here: commit 9fdb675fc should have checked
constisnull, didn't.
Per report from Piotr Włodarczyk. Back-patch to v11 where
bug was introduced.
Discussion: https://postgr.es/m/CAP-dhMr+vRpwizEYjUjsiZ1vwqpohTm+3Pbdt6Pr7FEgPq9R0Q@mail.gmail.com
M src/backend/partitioning/partprune.c
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql
Clarify the default partition's role
commit : edc793d374af50df76efb0a7622b78f58f0d8124
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 8 Aug 2019 16:03:14 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 8 Aug 2019 16:03:14 -0400
Reviewed by Tom Lane and Amit Langote
Discussion: https://postgr.es/m/20190806222735.GA9535@alvherre.pgsql
M doc/src/sgml/ref/create_table.sgml
Fix certificate subjects in ldap test
commit : 4116420baeae614a2711e156f0c4e58adad172ba
author : Andrew Dunstan <andrew@dunslane.net>
date : Thu, 8 Aug 2019 14:57:48 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Thu, 8 Aug 2019 14:57:48 -0400
openssl doesn't like lower case subject attribute names. Error observed
in buildfarm results.
Backpatch to release 11.
M src/test/ldap/t/001_auth.pl
Doc: document permissions required for ANALYZE.
commit : a1008caf0ac6960cb32b8a4c9b24d371db2a32b3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 7 Aug 2019 18:09:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 7 Aug 2019 18:09:28 -0400
VACUUM's reference page had this text, but ANALYZE's didn't. That's
a clear oversight given that section 5.7 explicitly delegates the
responsibility to define permissions requirements to the individual
commands' man pages.
Per gripe from Isaac Morland. Back-patch to all supported branches.
Discussion: https://postgr.es/m/CAMsGm5fp3oBUs-2iRfii0iEO=fZuJALVyM2zJLhNTjG34gpAVQ@mail.gmail.com
M doc/src/sgml/ref/analyze.sgml
Fix some typos in jsonpath documentation
commit : 53d467246589de631ce1846105f990099219e737
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Wed, 7 Aug 2019 16:06:45 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Wed, 7 Aug 2019 16:06:45 +0300
Discussion: https://postgr.es/m/8B7FA3B4-328D-43D7-95A8-37B8891B8C78%40winand.at
Author: Markus Winand
Backpatch-through: 12
M doc/src/sgml/func.sgml
Fix typos in comments.
commit : ca8a57b6369322b5ffd915c130da5e902d7f970c
author : Etsuro Fujita <efujita@postgresql.org>
date : Wed, 7 Aug 2019 19:05:18 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Wed, 7 Aug 2019 19:05:18 +0900
M src/backend/partitioning/partbounds.c
Fix predicate-locking of HOT updated rows.
commit : f8d30182b121f0c38695498d6d386ffa96858e76
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 7 Aug 2019 12:40:49 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 7 Aug 2019 12:40:49 +0300
In serializable mode, heap_hot_search_buffer() incorrectly acquired a
predicate lock on the root tuple, not the returned tuple that satisfied
the visibility checks. As explained in README-SSI, the predicate lock does
not need to be copied or extended to other tuple versions, but for that to
work, the correct, visible, tuple version must be locked in the first
place.
The original SSI commit had this bug in it, but it was fixed back in 2013,
in commit 81fbbfe335. But unfortunately, it was reintroduced a few months
later in commit b89e151054. Wising up from that, add a regression test
to cover this, so that it doesn't get reintroduced again. Also, move the
code that sets 't_self', so that it happens at the same time that the
other HeapTuple fields are set, to make it more clear that all the code in
the loop operate on the "current" tuple in the chain, not the root tuple.
Bug spotted by Andres Freund, analysis and original fix by Thomas Munro,
test case and some additional changes to the fix by Heikki Linnakangas.
Backpatch to all supported versions (9.4).
Discussion: https://www.postgresql.org/message-id/20190731210630.nqhszuktygwftjty%40alap3.anarazel.de
M src/backend/access/heap/heapam.c
A src/test/isolation/expected/predicate-lock-hot-tuple.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/predicate-lock-hot-tuple.spec
Fix some incorrect parsing of time with time zone strings
commit : d8652ec55513260a1ae478f80ae3d7da6eb795e0
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 7 Aug 2019 18:17:34 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 7 Aug 2019 18:17:34 +0900
When parsing a timetz string with a dynamic timezone abbreviation or a
timezone not specified, it was possible to generate incorrect timestamps
based on a date which uses some non-initialized variables if the input
string did not specify fully a date to parse. This is already checked
when a full timezone spec is included in the input string, but the two
other cases mentioned above missed the same checks.
This gets fixed by generating an error as this input is invalid, or in
short when a date is not fully specified.
Valgrind was complaining about this problem.
Bug: #15910
Author: Alexander Lakhin
Discussion: https://postgr.es/m/15910-2eba5106b9aa0c61@postgresql.org
Backpatch-through: 9.4
M src/backend/utils/adt/datetime.c
M src/test/regress/expected/timetz.out
M src/test/regress/sql/timetz.sql
Fix intarray's GiST opclasses to not fail for empty arrays with <@.
commit : 2f76f4182935c56c897463447ae18f8c2308637a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 Aug 2019 18:04:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 Aug 2019 18:04:51 -0400
contrib/intarray considers "arraycol <@ constant-array" to be indexable,
but its GiST opclass code fails to reliably find index entries for empty
array values (which of course should trivially match such queries).
This is because the test condition to see whether we should descend
through a non-leaf node is wrong.
Unfortunately, empty array entries could be anywhere in the index,
as these index opclasses are currently designed. So there's no way
to fix this except by lobotomizing <@ indexscans to scan the whole
index ... which is what this patch does. That's pretty unfortunate:
the performance is now actually worse than a seqscan, in most cases.
We'd be better off to remove <@ from the GiST opclasses entirely,
and perhaps a future non-back-patchable patch will do so.
In the meantime, applications whose performance is adversely impacted
have a couple of options. They could switch to a GIN index, which
doesn't have this bug, or they could replace "arraycol <@ constant-array"
with "arraycol <@ constant-array AND arraycol && constant-array".
That will provide about the same performance as before, and it will find
all non-empty subsets of the given constant-array, which is all that
could reliably be expected of the query before.
While at it, add some more regression test cases to improve code
coverage of contrib/intarray.
In passing, adjust resize_intArrayType so that when it's returning an
empty array, it uses construct_empty_array for that rather than
cowboy hacking on the input array. While the hack produces an array
that looks valid for most purposes, it isn't bitwise equal to empty
arrays produced by other code paths, which could have subtle odd
effects. I don't think this code path is performance-critical
enough to justify such shortcuts. (Back-patch this part only as far
as v11; before commit 01783ac36 we were not careful about this in
other intarray code paths either.)
Back-patch the <@ fixes to all supported versions, since this was
broken from day one.
Patch by me; thanks to Alexander Korotkov for review.
Discussion: https://postgr.es/m/458.1565114141@sss.pgh.pa.us
M contrib/intarray/_int_gist.c
M contrib/intarray/_int_tool.c
M contrib/intarray/_intbig_gist.c
M contrib/intarray/expected/_int.out
M contrib/intarray/sql/_int.sql
Save Kerberos and LDAP daemon logs where the buildfarm can find them.
commit : 514e7e911fc205e0143167e99dcd8fe56d69e071
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 Aug 2019 17:08:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 6 Aug 2019 17:08:07 -0400
src/test/kerberos and src/test/ldap try to run private authentication
servers, which of course might fail. The logs from these servers
were being dropped into the tmp_check/ subdirectory, but they should
be put in tmp_check/log/, because the buildfarm will only capture
log files in that subdirectory. Without the log output there's
little hope of diagnosing buildfarm failures related to these servers.
Backpatch to v11 where these test suites were added.
Discussion: https://postgr.es/m/16017.1565047605@sss.pgh.pa.us
M src/test/kerberos/t/001_auth.pl
M src/test/ldap/t/001_auth.pl
Stamp 12beta3.
commit : 7c45b994f125257be86df27583a6502348785186
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Aug 2019 17:10:44 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Aug 2019 17:10:44 -0400
M configure
M configure.in
M src/include/pg_config.h.win32
Fix choice of comparison operators for cross-type hashed subplans.
commit : de4b75c1549ac0baf45b4bcb8d49e2fac90ac43a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Aug 2019 11:20:21 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 5 Aug 2019 11:20:21 -0400
Commit bf6c614a2 rearranged the lookup of the comparison operators
needed in a hashed subplan, and in so doing, broke the cross-type
case: it caused the original LHS-vs-RHS operator to be used to compare
hash table entries too (which of course are all of the RHS type).
This leads to C functions being passed a Datum that is not of the
type they expect, with the usual hazards of crashes and unauthorized
server memory disclosure.
For the set of hashable cross-type operators present in v11 core
Postgres, this bug is nearly harmless on 64-bit machines, which
may explain why it escaped earlier detection. But it is a live
security hazard on 32-bit machines; and of course there may be
extensions that add more hashable cross-type operators, which
would increase the risk.
Reported by Andreas Seltenreich. Back-patch to v11 where the
problem came in.
Security: CVE-2019-10209
M src/backend/executor/nodeSubplan.c
M src/test/regress/expected/subselect.out
M src/test/regress/sql/subselect.sql
Require the schema qualification in pg_temp.type_name(arg).
commit : 9993fa9dd25d01e99748869b1fb1d6f4dc03960e
author : Noah Misch <noah@leadboat.com>
date : Mon, 5 Aug 2019 07:48:41 -0700
committer: Noah Misch <noah@leadboat.com>
date : Mon, 5 Aug 2019 07:48:41 -0700
Commit aa27977fe21a7dfa4da4376ad66ae37cb8f0d0b5 introduced this
restriction for pg_temp.function_name(arg); do likewise for types
created in temporary schemas. Programs that this breaks should add
"pg_temp." schema qualification or switch to arg::type_name syntax.
Back-patch to 9.4 (all supported versions).
Reviewed by Tom Lane. Reported by Tom Lane.
Security: CVE-2019-10208
M doc/src/sgml/config.sgml
M src/backend/catalog/namespace.c
M src/backend/parser/parse_func.c
M src/backend/parser/parse_type.c
M src/backend/utils/adt/ruleutils.c
M src/include/catalog/namespace.h
M src/include/parser/parse_type.h
M src/test/regress/expected/temp.out
M src/test/regress/sql/temp.sql
Translation updates
commit : 106c6635b5d9ca37b856bbd27560050c438a8ec9
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 5 Aug 2019 15:54:23 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 5 Aug 2019 15:54:23 +0200
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: e255bc8b15d0f173f9de9048d3d6ad6e40085a48
M src/backend/po/fr.po
M src/backend/po/ja.po
M src/backend/po/sv.po
M src/backend/po/tr.po
M src/backend/po/zh_CN.po
M src/bin/initdb/po/ja.po
M src/bin/initdb/po/sv.po
M src/bin/initdb/po/tr.po
M src/bin/initdb/po/zh_CN.po
M src/bin/pg_archivecleanup/nls.mk
M src/bin/pg_archivecleanup/po/ja.po
A src/bin/pg_archivecleanup/po/zh_CN.po
M src/bin/pg_basebackup/po/de.po
M src/bin/pg_basebackup/po/ja.po
M src/bin/pg_basebackup/po/sv.po
M src/bin/pg_basebackup/po/zh_CN.po
M src/bin/pg_checksums/nls.mk
A src/bin/pg_checksums/po/ja.po
M src/bin/pg_checksums/po/sv.po
A src/bin/pg_checksums/po/tr.po
M src/bin/pg_config/po/ja.po
M src/bin/pg_config/po/zh_CN.po
M src/bin/pg_controldata/po/ja.po
M src/bin/pg_controldata/po/zh_CN.po
M src/bin/pg_ctl/po/ja.po
M src/bin/pg_ctl/po/zh_CN.po
M src/bin/pg_dump/po/ja.po
M src/bin/pg_dump/po/sv.po
M src/bin/pg_dump/po/zh_CN.po
M src/bin/pg_resetwal/po/ja.po
M src/bin/pg_resetwal/po/zh_CN.po
M src/bin/pg_rewind/po/ja.po
M src/bin/pg_rewind/po/sv.po
M src/bin/pg_rewind/po/zh_CN.po
M src/bin/pg_test_fsync/nls.mk
A src/bin/pg_test_fsync/po/zh_CN.po
M src/bin/pg_test_timing/nls.mk
A src/bin/pg_test_timing/po/zh_CN.po
M src/bin/pg_upgrade/nls.mk
M src/bin/pg_upgrade/po/de.po
M src/bin/pg_upgrade/po/ja.po
M src/bin/pg_upgrade/po/sv.po
A src/bin/pg_upgrade/po/zh_CN.po
M src/bin/pg_waldump/nls.mk
M src/bin/pg_waldump/po/ja.po
A src/bin/pg_waldump/po/zh_CN.po
M src/bin/psql/po/ja.po
M src/bin/psql/po/tr.po
M src/bin/psql/po/zh_CN.po
M src/bin/scripts/po/ja.po
M src/bin/scripts/po/zh_CN.po
M src/interfaces/ecpg/ecpglib/po/ja.po
M src/interfaces/ecpg/ecpglib/po/zh_CN.po
M src/interfaces/ecpg/preproc/po/ja.po
M src/interfaces/ecpg/preproc/po/zh_CN.po
M src/interfaces/libpq/po/fr.po
M src/interfaces/libpq/po/ja.po
M src/interfaces/libpq/po/sv.po
M src/interfaces/libpq/po/zh_CN.po
M src/pl/plperl/po/ja.po
M src/pl/plperl/po/zh_CN.po
M src/pl/plpgsql/src/po/ja.po
M src/pl/plpgsql/src/po/zh_CN.po
M src/pl/plpython/po/ja.po
M src/pl/plpython/po/zh_CN.po
M src/pl/tcl/po/ja.po
M src/pl/tcl/po/zh_CN.po
Fix tab completion for ALTER LANGUAGE in psql
commit : 159e4bf7406f0cd46aae3f3873d28bdc63c110bf
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 5 Aug 2019 14:30:05 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 5 Aug 2019 14:30:05 +0900
OWNER_TO was used for the completion, which is not a supported grammar,
but OWNER TO is.
This error has been introduced by d37b816, so backpatch down to 9.6.
Author: Alexander Lakhin
Discussion: https://postgr.es/m/7ab243e0-116d-3e44-d120-76b3df7abefd@gmail.com
Backpatch-through: 9.6
M src/bin/psql/tab-complete.c
Adjust v12 release notes for reversion of log_statement_sample_rate.
commit : 2c133db2b42029a7df7d5d6cde48a898c6ca3ef0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Aug 2019 18:11:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Aug 2019 18:11:22 -0400
Necessary, not optional, because dangling link prevents relnotes from
building.
M doc/src/sgml/release-12.sgml
Revert "Add log_statement_sample_rate parameter"
commit : d5f53a8e26caf7931db6ad3939cd34d36ea54d91
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Sun, 4 Aug 2019 20:29:00 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Sun, 4 Aug 2019 20:29:00 +0200
This reverts commit 88bdbd3f746049834ae3cc972e6e650586ec3c9d.
As committed, statement sampling used the existing duration threshold
(log_min_duration_statement) when decide which statements to sample.
The issue is that even the longest statements are subject to sampling,
and so may not end up logged. An improvement was proposed, introducing
a second duration threshold, but it would not be backwards compatible.
So we've decided to revert this feature - the separate threshold should
be part of the feature itself.
Discussion: https://postgr.es/m/CAFj8pRDS8tQ3Wviw9%3DAvODyUciPSrGeMhJi_WPE%2BEB8%2B4gLL-Q%40mail.gmail.com
M doc/src/sgml/config.sgml
M src/backend/tcop/postgres.c
M src/backend/utils/misc/guc.c
M src/backend/utils/misc/postgresql.conf.sample
M src/include/utils/guc.h
Revert "Silence compiler warning"
commit : d8453ccfbfd6bb1782e71beb28acf4025a9a01ce
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Sun, 4 Aug 2019 20:19:54 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Sun, 4 Aug 2019 20:19:54 +0200
This reverts commit 9dc122585551516309c9362e673effdbf3bd79bd.
As committed, statement sampling used the existing duration threshold
(log_min_duration_statement) when decide which statements to sample.
The issue is that even the longest statements are subject to sampling,
and so may not end up logged. An improvement was proposed, introducing
a second duration threshold, but it would not be backwards compatible.
So we've decided to revert this feature - the separate threshold should
be part of the feature itself.
Discussion: https://postgr.es/m/CAFj8pRDS8tQ3Wviw9%3DAvODyUciPSrGeMhJi_WPE%2BEB8%2B4gLL-Q%40mail.gmail.com
M src/backend/tcop/postgres.c
Fix handling of "undef" in contrib/jsonb_plperl.
commit : df521ab79547b82471126e54e9dc7fead4a5a4fb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Aug 2019 14:05:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Aug 2019 14:05:35 -0400
Perl has multiple internal representations of "undef", and just
testing for SvTYPE(x) == SVt_NULL doesn't recognize all of them,
leading to "cannot transform this Perl type to jsonb" errors.
Use the approved test SvOK() instead.
Report and patch by Ivan Panchenko. Back-patch to v11 where
this module was added.
Discussion: https://postgr.es/m/1564783533.324795401@f193.i.mail.ru
M contrib/jsonb_plperl/expected/jsonb_plperl.out
M contrib/jsonb_plperl/expected/jsonb_plperlu.out
M contrib/jsonb_plperl/jsonb_plperl.c
M contrib/jsonb_plperl/sql/jsonb_plperl.sql
M contrib/jsonb_plperl/sql/jsonb_plperlu.sql
Avoid picking already-bound TCP ports in kerberos and ldap test suites.
commit : 4844c6303296d4fa2c9cc800685e4f404dfa5396
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Aug 2019 13:07:12 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 4 Aug 2019 13:07:12 -0400
src/test/kerberos and src/test/ldap need to run a private authentication
server of the relevant type, for which they need a free TCP port.
They were just picking a random port number in 48K-64K, which works
except when something's already using the particular port. Notably,
the probability of failure rises dramatically if one simply runs those
tests in a tight loop, because each test cycle leaves behind a bunch of
high ports that are transiently in TIME_WAIT state.
To fix, split out the code that PostgresNode.pm already had for
identifying a free TCP port number, so that it can be invoked to choose
a port for the KDC or LDAP server. This isn't 100% bulletproof, since
conceivably something else on the machine could grab the port between
the time we check and the time we actually start the server. But that's
a pretty short window, so in practice this should be good enough.
Back-patch to v11 where these test suites were added.
Patch by me, reviewed by Andrew Dunstan.
Discussion: https://postgr.es/m/3397.1564872168@sss.pgh.pa.us
M src/test/kerberos/t/001_auth.pl
M src/test/ldap/t/001_auth.pl
M src/test/perl/PostgresNode.pm
Improve pruning of a default partition
commit : 86544071484a48c753e719e0c7c9cf816a59a65e
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sun, 4 Aug 2019 11:18:45 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sun, 4 Aug 2019 11:18:45 -0400
When querying a partitioned table containing a default partition, we
were wrongly deciding to include it in the scan too early in the
process, failing to exclude it in some cases. If we reinterpret the
PruneStepResult.scan_default flag slightly, we can do a better job at
detecting that it can be excluded. The change is that we avoid setting
the flag for that pruning step unless the step absolutely requires the
default partition to be scanned (in contrast with the previous
arrangement, which was to set it unless the step was able to prune it).
So get_matching_partitions() must explicitly check the partition that
each returned bound value corresponds to in order to determine whether
the default one needs to be included, rather than relying on the flag
from the final step result.
Author: Yuzuko Hosoya <hosoya.yuzuko@lab.ntt.co.jp>
Reviewed-by: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Discussion: https://postgr.es/m/00e601d4ca86$932b8bc0$b982a340$@lab.ntt.co.jp
M src/backend/partitioning/partprune.c
M src/include/partitioning/partbounds.h
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql
Make relnote item wording consistent
commit : d58c9c0e9f408da7e9bf1901a39ab1ff12f310c0
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sun, 4 Aug 2019 01:30:12 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sun, 4 Aug 2019 01:30:12 -0400
M doc/src/sgml/release-12.sgml
Fix representation of hash keys in Hash/HashJoin nodes.
commit : a668bc75996daaa155442915c73a2c4dab2ac999
author : Andres Freund <andres@anarazel.de>
date : Fri, 2 Aug 2019 00:02:49 -0700
committer: Andres Freund <andres@anarazel.de>
date : Fri, 2 Aug 2019 00:02:49 -0700
In 5f32b29c1819 I changed the creation of HashState.hashkeys to
actually use HashState as the parent (instead of HashJoinState, which
was incorrect, as they were executed below HashState), to fix the
problem of hashkeys expressions otherwise relying on slot types
appropriate for HashJoinState, rather than HashState as would be
correct. That reliance was only introduced in 12, which is why it
previously worked to use HashJoinState as the parent (although I'd be
unsurprised if there were problematic cases).
Unfortunately that's not a sufficient solution, because before this
commit, the to-be-hashed expressions referenced inner/outer as
appropriate for the HashJoin, not Hash. That didn't have obvious bad
consequences, because the slots containing the tuples were put into
ecxt_innertuple when hashing a tuple for HashState (even though Hash
doesn't have an inner plan).
There are less common cases where this can cause visible problems
however (rather than just confusion when inspecting such executor
trees). E.g. "ERROR: bogus varno: 65000", when explaining queries
containing a HashJoin where the subsidiary Hash node's hash keys
reference a subplan. While normally hashkeys aren't displayed by
EXPLAIN, if one of those expressions references a subplan, that
subplan may be printed as part of the Hash node - which then failed
because an inner plan was referenced, and Hash doesn't have that.
It seems quite possible that there's other broken cases, too.
Fix the problem by properly splitting the expression for the HashJoin
and Hash nodes at plan time, and have them reference the proper
subsidiary node. While other workarounds are possible, fixing this
correctly seems easy enough. It was a pretty ugly hack to have
ExecInitHashJoin put the expression into the already initialized
HashState, in the first place.
I decided to not just split inner/outer hashkeys inside
make_hashjoin(), but also to separate out hashoperators and
hashcollations at plan time. Otherwise we would have ended up having
two very similar loops, one at plan time and the other during executor
startup. The work seems to more appropriately belong to plan time,
anyway.
Reported-By: Nikita Glukhov, Alexander Korotkov
Author: Andres Freund
Reviewed-By: Tom Lane, in an earlier version
Discussion: https://postgr.es/m/CAPpHfdvGVegF_TKKRiBrSmatJL2dR9uwFCuR+teQ_8tEXU8mxg@mail.gmail.com
Backpatch: 12-
M src/backend/executor/nodeHash.c
M src/backend/executor/nodeHashjoin.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/outfuncs.c
M src/backend/nodes/readfuncs.c
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/plan/setrefs.c
M src/include/nodes/execnodes.h
M src/include/nodes/plannodes.h
M src/test/regress/expected/join_hash.out
M src/test/regress/sql/join_hash.sql
Fix handling of previous password hooks in passwordcheck
commit : 20f5cb19582e62e5664e87f7d6963cb8db1628f9
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 1 Aug 2019 09:37:48 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 1 Aug 2019 09:37:48 +0900
When piling up loading of modules using check_password_hook_type,
loading passwordcheck would remove any trace of a previously-loaded
hook. Unloading the module would also cause previous hooks to be
entirely gone.
Reported-by: Rafael Castro
Author: Michael Paquier
Reviewed-by: Daniel Gustafsson
Discussion: https://postgr.es/m/15932-78f48f9ef166778c@postgresql.org
Backpatch-through: 9.4
M contrib/passwordcheck/passwordcheck.c
Fix pg_dump's handling of dependencies for custom opclasses.
commit : 408f759380c723b94e9fb8b523aa02509e1e1d6e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 31 Jul 2019 15:42:50 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 31 Jul 2019 15:42:50 -0400
Since pg_dump doesn't treat the member operators and functions of operator
classes/families (that is, the pg_amop and pg_amproc entries, not the
underlying operators/functions) as separate dumpable objects, it missed
their dependency information. I think this was safe when the code was
designed, because the default object sorting rule emits operators and
functions before opclasses, and there were no dependency types that could
mess that up. However, the introduction of range types in 9.2 broke it:
now a type can have a dependency on an opclass, allowing dependency rules
to push the opclass before the type and hence before custom operators.
Lacking any information showing that it shouldn't do so, pg_dump emitted
the objects in the wrong order.
Fix by teaching getDependencies() to translate pg_depend entries for
pg_amop/amproc rows to look like dependencies for their parent opfamily.
I added a regression test for this in HEAD/v12, but not further back;
life is too short to fight with 002_pg_dump.pl.
Per bug #15934 from Tom Gottfried. Back-patch to all supported branches.
Discussion: https://postgr.es/m/15934-58b8c8ab7a09ea15@postgresql.org
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/t/002_pg_dump.pl
Remove superfluous newlines in function prototypes.
commit : c4b7bb3cf19f5d847544de93c36329de8e59193b
author : Andres Freund <andres@anarazel.de>
date : Wed, 31 Jul 2019 00:05:21 -0700
committer: Andres Freund <andres@anarazel.de>
date : Wed, 31 Jul 2019 00:05:21 -0700
These were introduced by pgindent due to fixe to broken
indentation (c.f. 8255c7a5eeba8). Previously the mis-indentation of
function prototypes was creatively used to reduce indentation in a few
places.
As that formatting only exists in master and REL_12_STABLE, it seems
better to fix it in both, rather than having some odd indentation in
v12 that somebody might copy for future patches or such.
Author: Andres Freund
Discussion: https://postgr.es/m/20190728013754.jwcbe5nfyt3533vx@alap3.anarazel.de
Backpatch: 12-
M src/backend/commands/event_trigger.c
M src/backend/executor/nodeBitmapHeapscan.c
M src/backend/libpq/auth.c
M src/backend/storage/ipc/sinval.c
M src/backend/utils/adt/jsonpath_exec.c
M src/include/access/gist_private.h
M src/include/replication/logical.h
M src/include/replication/reorderbuffer.h
M src/include/storage/sinval.h
M src/include/utils/guc.h
Allow table AM's to use rd_amcache, too.
commit : 394f7500ae8f4afc158273d642f5ce87af3a7309
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 30 Jul 2019 21:43:27 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 30 Jul 2019 21:43:27 +0300
The rd_amcache allows an index AM to cache arbitrary information in a
relcache entry. This commit moves the cleanup of rd_amcache so that it
can also be used by table AMs. Nothing takes advantage of that yet, but
I'm sure it'll come handy for anyone writing new table AMs.
Backpatch to v12, where table AM interface was introduced.
Reviewed-by: Julien Rouhaud
M src/backend/utils/cache/relcache.c
M src/include/utils/rel.h
Print WAL position correctly in pg_rewind error message.
commit : 718e313244a9376d823b5efe421eb079474a6b20
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 30 Jul 2019 21:14:14 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 30 Jul 2019 21:14:14 +0300
This has been wrong ever since pg_rewind was added. The if-branch just
above this, where we print the same error with an extra message supplied
by XLogReadRecord() got this right, but the variable name was wrong in the
else-branch. As a consequence, the error printed the WAL position as
0/0 if there was an error reading a WAL file.
Backpatch to 9.5, where pg_rewind was added.
M src/bin/pg_rewind/parsexlog.c
Don't build extended statistics on inheritance trees
commit : e1947f6c3ed8bda397295f555fa9e3fe39d50143
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Tue, 30 Jul 2019 19:17:12 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Tue, 30 Jul 2019 19:17:12 +0200
When performing ANALYZE on inheritance trees, we collect two samples for
each relation - one for the relation alone, and one for the inheritance
subtree (relation and its child relations). And then we build statistics
on each sample, so for each relation we get two sets of statistics.
For regular (per-column) statistics this works fine, because the catalog
includes a flag differentiating statistics built from those two samples.
But we don't have such flag in the extended statistics catalogs, and we
ended up updating the same row twice, triggering this error:
ERROR: tuple already updated by self
The simplest solution is to disable extended statistics on inheritance
trees, which is what this commit is doing. In the future we may need to
do something similar to per-column statistics, but that requires adding a
flag to the catalog - and that's not backpatchable. Moreover, the current
selectivity estimation code only works with individual relations, so
building statistics on inheritance trees would be pointless anyway.
Author: Tomas Vondra
Backpatch-to: 10-
Discussion: https://postgr.es/m/20190618231233.GA27470@telsasoft.com
Reported-by: Justin Pryzby
M src/backend/commands/analyze.c
M src/test/regress/expected/stats_ext.out
M src/test/regress/sql/stats_ext.sql
Fix busted logic for parallel lock grouping in TopoSort().
commit : d933816c04c64326419bbcd89dc17a4e310f950b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 29 Jul 2019 18:49:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 29 Jul 2019 18:49:04 -0400
A "break" statement erroneously left behind by commit a1c1af2a1
caused TopoSort to do the wrong thing if a lock's wait list
contained multiple members of the same locking group.
Because parallel workers don't normally need any locks not already
taken by their leader, this is very hard --- maybe impossible ---
to hit in production. Still, if it did happen, the queries involved
in an otherwise-resolvable deadlock would block until canceled.
In addition to removing the bogus "break", add an Assert showing
that the conflicting uses of the beforeConstraints[] array (for both
counts and flags) don't overlap, and add some commentary explaining
why not; because it's not obvious without explanation, IMHO.
Original report and patch from Rui Hai Jiang; additional assert
and commentary by me. Back-patch to 9.6 where the bug came in.
Discussion: https://postgr.es/m/CAEri+mLd3bpHLyW+a9pSe1y=aEkeuJpwBSwvo-+m4n7-ceRmXw@mail.gmail.com
M src/backend/storage/lmgr/deadlock.c
Fix handling of expressions and predicates in REINDEX CONCURRENTLY
commit : 28bbf7a81b3a30504cc7dfdbd76b410d1f127b8e
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 29 Jul 2019 09:58:49 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 29 Jul 2019 09:58:49 +0900
When copying the definition of an index rebuilt concurrently for the new
entry, the index information was taken directly from the old index using
the relation cache. In this case, predicates and expressions have
some post-processing to prepare things for the planner, which loses some
information including the collations added in any of them.
This inconsistency can cause issues when attempting for example a table
rewrite, and makes the new indexes rebuilt concurrently inconsistent
with the old entries.
In order to fix the problem, fetch expressions and predicates directly
from the catalog of the old entry, and fill in IndexInfo for the new
index with that. This makes the process more consistent with
DefineIndex(), and the code is refactored with the addition of a routine
to create an IndexInfo node.
Reported-by: Manuel Rigger
Author: Michael Paquier
Discussion: https://postgr.es/m/CA+u7OA5Hp0ra235F3czPom_FyAd-3+XwSJmX95r1+sRPOJc9VQ@mail.gmail.com
Backpatch-through: 12
M src/backend/catalog/index.c
M src/backend/commands/indexcmds.c
M src/backend/nodes/makefuncs.c
M src/include/nodes/makefuncs.h
M src/test/regress/expected/create_index.out
M src/test/regress/sql/create_index.sql
Avoid macro clash with LLVM 9.
commit : 180825fe43ece9bf13c27929b7fdeec5a457e9c3
author : Thomas Munro <tmunro@postgresql.org>
date : Mon, 29 Jul 2019 10:12:37 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Mon, 29 Jul 2019 10:12:37 +1200
Early previews of LLVM 9 reveal that our Min() macro causes compiler
errors in LLVM headers reached by the #include directives in
llvmjit_inline.cpp. Let's just undefine it. Per buildfarm animal
seawasp. Back-patch to 11.
Reviewed-by: Fabien Coelho, Tom Lane
Discussion: https://postgr.es/m/20190606173216.GA6306%40alvherre.pgsql
M src/backend/jit/llvm/llvmjit_inline.cpp
Doc: Fix event trigger firing table
commit : e396d1ee7db5027302bc8ce129b435dee13723a4
author : Michael Paquier <michael@paquier.xyz>
date : Sun, 28 Jul 2019 22:02:30 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sun, 28 Jul 2019 22:02:30 +0900
The table has not been updated for some commands introduced in recent
releases, so refresh it. While on it, reorder entries alphabetically.
Backpatch all the way down for all the commands which have gone
missing.
Reported-by: Jeremy Smith
Discussion: https://postgr.es/m/15883-afff0ea3cc2dbbb6@postgresql.org
Backpatch-through: 9.4
M doc/src/sgml/event-trigger.sgml
pg_upgrade: Update obsolescent documentation note
commit : 66190f371d8a6fd7d2ab50187041ce1da44cbb3b
author : Peter Eisentraut <peter@eisentraut.org>
date : Sat, 27 Jul 2019 08:26:33 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sat, 27 Jul 2019 08:26:33 +0200
Recently released xfsprogs 5.1.0 has reflink support enabled by
default, so the note that it's not enabled by default can be removed.
M doc/src/sgml/ref/pgupgrade.sgml
Don't uselessly escape a string that doesn't need escaping
commit : 5ac684381df1783b0855d3b53b1c6d4736843695
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 26 Jul 2019 17:46:40 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 26 Jul 2019 17:46:40 -0400
Per gripe from Ian Barwick
Co-authored-by: Ian Barwick <ian@2ndquadrant.com>
Discussion: https://postgr.es/m/CABvVfJWNnNKb8cHsTLhkTsvL1+G6BVcV+57+w1JZ61p8YGPdWQ@mail.gmail.com
M src/bin/pg_basebackup/pg_basebackup.c
Tweak our special-case logic for the IANA "Factory" timezone.
commit : d095b2fe676a929837715ece04ae19e0d8a1dcc3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Jul 2019 13:07:08 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Jul 2019 13:07:08 -0400
pg_timezone_names() tries to avoid showing the "Factory" zone in
the view, mainly because that has traditionally had a very long
"abbreviation" such as "Local time zone must be set--see zic manual page",
so that showing it messes up psql's formatting of the whole view.
Since tzdb version 2016g, IANA instead uses the abbreviation "-00",
which is sane enough that there's no reason to discriminate against it.
On the other hand, it emerges that FreeBSD and possibly other packagers
are so wedded to backwards compatibility that they hack the IANA data
to keep the old spelling --- and not just that old spelling, but even
older spellings that IANA used back in the stone age. This caused the
filter logic to fail to suppress "Factory" at all on such platforms,
though the formatting problem is definitely real in that case.
To solve both problems, get rid of the hard-wired assumption about
exactly what Factory's abbreviation is, and instead reject abbreviations
exceeding 31 characters. This will allow Factory to appear in the view
if and only if it's using the modern abbreviation.
In passing, simplify the code we add to zic.c to support "zic -P"
to remove its now-obsolete hacks to not print the Factory zone's
abbreviation. Unlike pg_timezone_names(), there's no reason for
that code to support old/nonstandard timezone data.
Since we generally prefer to keep timezone-related behavior the
same in all branches, and since this is arguably a bug fix,
back-patch to all supported branches.
Discussion: https://postgr.es/m/3961.1564086915@sss.pgh.pa.us
M src/backend/utils/adt/datetime.c
M src/timezone/zic.c
Avoid choosing "localtime" or "posixrules" as TimeZone during initdb.
commit : e31dfe99c8c686726c09c4bdf9d4e2c78fd5fc37
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Jul 2019 12:45:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Jul 2019 12:45:32 -0400
Some platforms create a file named "localtime" in the system
timezone directory, making it a copy or link to the active time
zone file. If Postgres is built with --with-system-tzdata, initdb
will see that file as an exact match to localtime(3)'s behavior,
and it may decide that "localtime" is the most preferred spelling of
the active zone. That's a very bad choice though, because it's
neither informative, nor portable, nor stable if someone changes
the system timezone setting. Extend the preference logic added by
commit e3846a00c so that we will prefer any other zone file that
matches localtime's behavior over "localtime".
On the same logic, also discriminate against "posixrules", which
is another not-really-a-zone file that is often present in the
timezone directory. (Since we install "posixrules" but not
"localtime", this change can affect the behavior of Postgres
with or without --with-system-tzdata.)
Note that this change doesn't prevent anyone from choosing these
pseudo-zones if they really want to (i.e., by setting TZ for initdb,
or modifying the timezone GUC later on). It just prevents initdb
from preferring these zone names when there are multiple matches to
localtime's behavior.
Since we generally prefer to keep timezone-related behavior the
same in all branches, and since this is arguably a bug fix,
back-patch to all supported branches.
Discussion: https://postgr.es/m/CADT4RqCCnj6FKLisvT8tTPfTP4azPhhDFJqDF1JfBbOH5w4oyQ@mail.gmail.com
Discussion: https://postgr.es/m/27991.1560984458@sss.pgh.pa.us
M src/bin/initdb/findtimezone.c
Fix loss of fractional digits for large values in cash_numeric().
commit : 01e0538e8b12591283835a2ff629428262684574
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Jul 2019 11:59:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 26 Jul 2019 11:59:00 -0400
Money values exceeding about 18 digits (depending on lc_monetary)
could be inaccurately converted to numeric, due to select_div_scale()
deciding it didn't need to compute any fractional digits. Force
its hand by setting the dscale of one division input to equal the
number of fractional digits we need.
In passing, rearrange the logic to not do useless work in locales
where money values are considered integral.
Per bug #15925 from Slawomir Chodnicki. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/15925-da9953e2674bb5c8@postgresql.org
M src/backend/utils/adt/cash.c
M src/test/regress/expected/money.out
M src/test/regress/sql/money.sql
doc: PG 12 relnotes - add item about amcheck index root check
commit : ba2347a6d985afc19d4c8e8e84b16a28ed4df137
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 25 Jul 2019 21:37:04 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 25 Jul 2019 21:37:04 -0400
Reported-by: Peter Geoghegan
Discussion: https://postgr.es/m/LGbT2ncB7tiDsndK0eXHTKmogLjJ5rO52HqXigP8bCA@mail.gmail.com
Backpatch-through: 12
M doc/src/sgml/release-12.sgml
doc: PG 12 relnotes, add item - pg_test_fsync fix on Windows
commit : 551394ff3a35090873f359995568b661c60a7376
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 25 Jul 2019 21:05:51 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 25 Jul 2019 21:05:51 -0400
Reported-by: Laurenz Albe
Discussion: https://postgr.es/m/39fd196ca3af345f67595087519268d9da6891b3.camel@cybertec.at
Backpatch-through: 12
M doc/src/sgml/release-12.sgml
Fix LDAP test instability.
commit : 3964d3bce9ca1e45301f99800fc798768f7b57ac
author : Thomas Munro <tmunro@postgresql.org>
date : Fri, 26 Jul 2019 10:01:18 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Fri, 26 Jul 2019 10:01:18 +1200
After starting slapd, wait until it can accept a connection before
beginning the real test work. This avoids occasional test failures.
Back-patch to 11, where the LDAP tests arrived.
Author: Thomas Munro
Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/20190719033013.GI1859%40paquier.xyz
M src/test/ldap/t/001_auth.pl
Add missing (COSTS OFF) to EXPLAIN added in previous commit.
commit : c4944a93eb526f3799a36f30d46d6e765108b2b4
author : Andres Freund <andres@anarazel.de>
date : Thu, 25 Jul 2019 14:50:48 -0700
committer: Andres Freund <andres@anarazel.de>
date : Thu, 25 Jul 2019 14:50:48 -0700
Backpatch: 12-, like the previous commit
M src/test/regress/expected/groupingsets.out
M src/test/regress/sql/groupingsets.sql
Fix slot type handling for Agg nodes performing internal sorts.
commit : 8677c62eaeea002712dd71dc678a7a0566e59858
author : Andres Freund <andres@anarazel.de>
date : Thu, 25 Jul 2019 14:22:52 -0700
committer: Andres Freund <andres@anarazel.de>
date : Thu, 25 Jul 2019 14:22:52 -0700
Since 15d8f8312 we assert that - and since 7ef04e4d2cb2, 4da597edf1
rely on - the slot type for an expression's
ecxt_{outer,inner,scan}tuple not changing, unless explicitly flagged
as such. That allows to either skip deforming (for a virtual tuple
slot) or optimize the code for JIT accelerated deforming
appropriately (for other known slot types).
This assumption was sometimes violated for grouping sets, when
nodeAgg.c internally uses tuplesorts, and the child node doesn't
return a TTSOpsMinimalTuple type slot. Detect that case, and flag that
the outer slot might not be "fixed".
It's probably worthwhile to optimize this further in the future, and
more granularly determine whether the slot is fixed. As we already
instantiate per-phase transition and equal expressions, we could
cheaply set the slot type appropriately for each phase. But that's a
separate change from this bugfix.
This commit does include a very minor optimization by avoiding to
create a slot for handling tuplesorts, if no such sorts are
performed. Previously we created that slot unnecessarily in the common
case of computing all grouping sets via hashing. The code looked too
confusing without that, as the conditions for needing a sort slot and
flagging that the slot type isn't fixed, are the same.
Reported-By: Ashutosh Sharma
Author: Andres Freund
Discussion: https://postgr.es/m/CAE9k0PmNaMD2oHTEAhRyxnxpaDaYkuBYkLa1dpOpn=RS0iS2AQ@mail.gmail.com
Backpatch: 12-, where the bug was introduced in 15d8f8312
M src/backend/executor/nodeAgg.c
M src/test/regress/expected/groupingsets.out
M src/test/regress/sql/groupingsets.sql
Fix syntax error in commit 20e99cddd.
commit : b2453704673469ffd34ed13a642e3edc936f5a24
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 25 Jul 2019 14:42:02 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 25 Jul 2019 14:42:02 -0400
Per buildfarm.
M src/tools/msvc/MSBuildProject.pm
Fix failures to ignore \r when reading Windows-style newlines.
commit : c58cf97f2fc464e15f0cca95b9d31b7224d48ecd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 25 Jul 2019 12:10:54 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 25 Jul 2019 12:10:54 -0400
libpq failed to ignore Windows-style newlines in connection service files.
This normally wasn't a problem on Windows itself, because fgets() would
convert \r\n to just \n. But if libpq were running inside a program that
changes the default fopen mode to binary, it would see the \r's and think
they were data. In any case, it's project policy to ignore \r in text
files unconditionally, because people sometimes try to use files with
DOS-style newlines on Unix machines, where the C library won't hide that
from us.
Hence, adjust parseServiceFile() to ignore \r as well as \n at the end of
the line. In HEAD, go a little further and make it ignore all trailing
whitespace, to match what it's always done with leading whitespace.
In HEAD, also run around and fix up everyplace where we have
newline-chomping code to make all those places look consistent and
uniformly drop \r. It is not clear whether any of those changes are
fixing live bugs. Most of the non-cosmetic changes are in places that
are reading popen output, and the jury is still out as to whether popen
on Windows can return \r\n. (The Windows-specific code in pipe_read_line
seems to think so, but our lack of support for this elsewhere suggests
maybe it's not a problem in practice.) Hence, I desisted from applying
those changes to back branches, except in run_ssl_passphrase_command()
which is new enough and little-tested enough that we'd probably not have
heard about any problems there.
Tom Lane and Michael Paquier, per bug #15827 from Jorge Gustavo Rocha.
Back-patch the parseServiceFile() change to all supported branches,
and the run_ssl_passphrase_command() change to v11 where that was added.
Discussion: https://postgr.es/m/15827-e6ba53a3a7ed543c@postgresql.org
M src/backend/libpq/be-secure-common.c
M src/interfaces/libpq/fe-connect.c
Honor MSVC WindowsSDKVersion if set
commit : 6e5417d7737bdcc26ca7889210f275a8e46591b0
author : Andrew Dunstan <andrew@dunslane.net>
date : Thu, 25 Jul 2019 11:24:23 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Thu, 25 Jul 2019 11:24:23 -0400
Add a line to the project file setting the target SDK. Otherwise, in for
example VS2017, if the default but optional 8.1 SDK is not installed the
build will fail.
Patch from Peifeng Qiu, slightly edited by me.
Discussion: https://postgr.es/m/CABmtVJhw1boP_bd4=b3Qv5YnqEdL696NtHFi2ruiyQ6mFHkeQQ@mail.gmail.com
Backpatch to all live branches.
M src/tools/msvc/MSBuildProject.pm
Fix contrib/sepgsql test policy to work with latest SELinux releases.
commit : 665329abe7effa688dd96b34a0130109b669d36d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 25 Jul 2019 11:02:43 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 25 Jul 2019 11:02:43 -0400
As of Fedora 30, it seems that the system-provided macros for setting
up user privileges in SELinux policies don't grant the ability to read
/etc/passwd, as they formerly did. This restriction breaks psql
(which tries to use getpwuid() to obtain the user name it's running
under) and thereby the contrib/sepgsql regression test. Add explicit
specifications that we need the right to read /etc/passwd.
Mike Palmiotto, per a report from me. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/23856.1563381159@sss.pgh.pa.us
M contrib/sepgsql/sepgsql-regtest.te
doc: Fix typo
commit : 2e60117aa9152ca11b54e95a41f72f71a2387f33
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 25 Jul 2019 13:58:53 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 25 Jul 2019 13:58:53 +0200
M doc/src/sgml/libpq.sgml
Fix system column accesses in ON CONFLICT ... RETURNING.
commit : f9257cffef3bb16aba2dbbe05fd8bf0afaa6b1f2
author : Andres Freund <andres@anarazel.de>
date : Wed, 24 Jul 2019 18:45:58 -0700
committer: Andres Freund <andres@anarazel.de>
date : Wed, 24 Jul 2019 18:45:58 -0700
After 277cb789836 ON CONFLICT ... SET ... RETURNING failed with
ERROR: virtual tuple table slot does not have system attributes
when taking the update path, as the slot used to insert into the
table (and then process RETURNING) was defined to be a virtual slot in
that commit. Virtual slots don't support system columns except for
tableoid and ctid, as the other system columns are AM dependent.
Fix that by using a slot of the table's type. Add tests for system
column accesses in ON CONFLICT ... RETURNING.
Reported-By: Roby, bisected to the relevant commit by Jeff Janes
Author: Andres Freund
Discussion: https://postgr.es/m/73436355-6432-49B1-92ED-1FE4F7E7E100@finefun.com.au
Backpatch: 12-, where the bug was introduced in 277cb789836
M src/backend/executor/nodeModifyTable.c
M src/test/regress/expected/update.out
M src/test/regress/sql/update.sql
Fix failure with pgperlcritic from the TAP test of synchronous replication
commit : 24a6b6af650132094f7f8547458a3835cf01be7f
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 25 Jul 2019 07:55:28 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 25 Jul 2019 07:55:28 +0900
Oversight in 7d81bdc, which introduced a new routine in perl lacking a
return clause. Per buildfarm member crake.
Backpatch down to 9.6 like its parent.
Reported-by: Andrew Dunstan
Discussion: https://postgr.es/m/16da29fa-d504-1380-7095-40de586dc038@2ndQuadrant.com
Backpatch-through: 9.6
M src/test/recovery/t/007_sync_rep.pl
Fix infelicities in describeOneTableDetails' partitioned-table handling.
commit : d16e514befb5fdcf59bb404e828d3ce88a829b8e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 24 Jul 2019 18:14:26 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 24 Jul 2019 18:14:26 -0400
describeOneTableDetails issued a partition-constraint-fetching query
for every table, even ones it knows perfectly well are not partitions.
To add insult to injury, it then proceeded to leak the empty PGresult
if the table wasn't a partition. Doing that a lot of times might
amount to a meaningful leak, so this seems like a back-patchable bug.
Fix that, and also fix a related PGresult leak in the partition-parent
case (though that leak would occur only if we got no row, which is
unexpected).
Minor code beautification too, to make this code look more like the
pre-existing code around it.
Back-patch the whole change into v12. However, the fact that we already
know whether the table is a partition dates only to commit 1af25ca0c;
back-patching the relevant changes from that is probably more churn
than is justified in released branches. Hence, in v11 and v10, just
do the minimum to fix the PGresult leaks.
Noted while messing around with adjacent code for yesterday's \d
improvements.
M src/bin/psql/describe.c
Use full 64-bit XID for checking if a deleted GiST page is old enough.
commit : fb5344c969af77bb78bc2a643fb75b9f8fea72dd
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 24 Jul 2019 20:24:07 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 24 Jul 2019 20:24:07 +0300
Otherwise, after a deleted page gets even older, it becomes unrecyclable
again. B-tree has the same problem, and has had since time immemorial,
but let's at least fix this in GiST, where this is new.
Backpatch to v12, where GiST page deletion was introduced.
Reviewed-by: Andrey Borodin
Discussion: https://www.postgresql.org/message-id/835A15A5-F1B4-4446-A711-BF48357EB602%40yandex-team.ru
M src/backend/access/gist/gistutil.c
M src/backend/access/gist/gistvacuum.c
M src/backend/access/gist/gistxlog.c
M src/backend/access/rmgrdesc/gistdesc.c
M src/backend/utils/time/snapmgr.c
M src/include/access/gist.h
M src/include/access/gist_private.h
M src/include/access/gistxlog.h
M src/include/utils/snapmgr.h
Refactor checks for deleted GiST pages.
commit : e2e992c93145cfc0e3563fb84efd25b390a84bb9
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 24 Jul 2019 20:24:05 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 24 Jul 2019 20:24:05 +0300
The explicit check in gistScanPage() isn't currently really necessary, as
a deleted page is always empty, so the loop would fall through without
doing anything, anyway. But it's a marginal optimization, and it gives a
nice place to attach a comment to explain how it works.
Backpatch to v12, where GiST page deletion was introduced.
Reviewed-by: Andrey Borodin
Discussion: https://www.postgresql.org/message-id/835A15A5-F1B4-4446-A711-BF48357EB602%40yandex-team.ru
M src/backend/access/gist/gist.c
M src/backend/access/gist/gistget.c
Don't assume expr is available in pgbench tests
commit : bfa4263e7119685cddb08ed2e2b3462157d4d453
author : Andrew Dunstan <andrew@dunslane.net>
date : Wed, 24 Jul 2019 11:41:39 -0400
committer: Andrew Dunstan <andrew@dunslane.net>
date : Wed, 24 Jul 2019 11:41:39 -0400
Windows hosts do not normally come with expr, so instead of using that
to test the \setshell command, use echo instead, which is fairly
universally available.
Backpatch to release 11, where this came in.
Problem found by me, patch by Fabien Coelho.
M src/bin/pgbench/t/001_pgbench_with_server.pl
Doc: Clarify interactions of pg_receivewal with remote_apply
commit : a15a40aaaedfa01f41471f74aa8ac44168603fb9
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 24 Jul 2019 11:26:24 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 24 Jul 2019 11:26:24 +0900
Using pg_receivewal with synchronous_commit = remote_apply set in the
backend is incompatible if pg_receivewal is a synchronous standby as it
never applies WAL, so document this problem and solutions to it.
Backpatch to 9.6, where remote_apply has been added.
Author: Robert Haas, Jesper Pedersen
Reviewed-by: Laurenz Albe, Álvaro Herrera, Michael Paquier
Discussion: https://postgr.es/m/1427a2d3-1e51-9335-1931-4f8853d90d5e@redhat.com
Backpatch-through: 9.6
M doc/src/sgml/ref/pg_receivewal.sgml
Improve stability of TAP test for synchronous replication
commit : 0ceb28da06152cbf69c7e9a71c09e9de47783472
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 24 Jul 2019 10:54:20 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 24 Jul 2019 10:54:20 +0900
Slow buildfarm machines have run into issues with this TAP test caused
by a race condition related to the startup of a set of standbys, where
it is possible to finish with an unexpected order in the WAL sender
array of the primary.
This closes the race condition by making sure that any standby started
is registered into the WAL sender array of the primary before starting
the next one based on lookups of pg_stat_replication.
Backpatch down to 9.6 where the test has been introduced.
Author: Michael Paquier
Reviewed-by: Álvaro Herrera, Noah Misch
Discussion: https://postgr.es/m/20190617055145.GB18917@paquier.xyz
Backpatch-through: 9.6
M src/test/recovery/t/007_sync_rep.pl
Check that partitions are not in use when dropping constraints
commit : 3ffe655c0af03cb4d5aab18da2aaa7022d207bf3
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 23 Jul 2019 17:22:15 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 23 Jul 2019 17:22:15 -0400
If the user creates a deferred constraint in a partition, and in a
transaction they cause the constraint's trigger execution to be deferred
until commit time *and* drop the constraint, then when commit time comes
the queued trigger will fail to run because the trigger object will have
been dropped.
This is explained because when a constraint gets dropped in a
partitioned table, the recursion to drop the ones in partitions is done
by the dependency mechanism, not by ALTER TABLE traversing the recursion
tree as in all other cases. In the non-partitioned case, this problem
is avoided by checking that the table is not "in use" by alter-table;
other alter-table subcommands that recurse to partitions do that check
for each partition. But the dependency mechanism doesn't have a way to
do that. Fix the problem by applying the same check to all partitions
during ALTER TABLE's "prep" phase, which correctly raises the necessary
error.
Reported-by: Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>
Discussion: https://postgr.es/m/CAKcux6nZiO9-eEpr1ZD84bT1mBoVmeZkfont8iSpcmYrjhGWgA@mail.gmail.com
M src/backend/commands/tablecmds.c
M src/test/regress/expected/foreign_key.out
M src/test/regress/sql/foreign_key.sql
Install dependencies to prevent dropping partition key columns.
commit : 79e573fa4986be54c30d1313709c26c2a34488c8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 22 Jul 2019 14:55:23 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 22 Jul 2019 14:55:23 -0400
The logic in ATExecDropColumn that rejects dropping partition key
columns is quite an inadequate defense, because it doesn't execute
in cases where a column needs to be dropped due to cascade from
something that only the column, not the whole partitioned table,
depends on. That leaves us with a badly broken partitioned table;
even an attempt to load its relcache entry will fail.
We really need to have explicit pg_depend entries that show that the
column can't be dropped without dropping the whole table. Hence,
add those entries. In v12 and HEAD, bump catversion to ensure that
partitioned tables will have such entries. We can't do that in
released branches of course, so in v10 and v11 this patch affords
protection only to partitioned tables created after the patch is
installed. Given the lack of field complaints (this bug was found
by fuzz-testing not by end users), that's probably good enough.
In passing, fix ATExecDropColumn and ATPrepAlterColumnType
messages to be more specific about which partition key column
they're complaining about.
Per report from Manuel Rigger. Back-patch to v10 where partitioned
tables were added.
Discussion: https://postgr.es/m/CA+u7OA4JKCPFrdrAbOs7XBiCyD61XJxeNav4LefkSmBLQ-Vobg@mail.gmail.com
Discussion: https://postgr.es/m/31920.1562526703@sss.pgh.pa.us
M src/backend/catalog/dependency.c
M src/backend/catalog/heap.c
M src/backend/commands/tablecmds.c
M src/bin/pg_dump/pg_dump_sort.c
M src/include/catalog/catversion.h
M src/include/catalog/dependency.h
M src/test/regress/expected/alter_table.out
M src/test/regress/expected/create_table.out
M src/test/regress/sql/create_table.sql
Don't rely on estimates for amcheck Bloom filters.
commit : 980224b4a23056de76d902b539980868d33d1b8d
author : Peter Geoghegan <pg@bowt.ie>
date : Sat, 20 Jul 2019 11:11:54 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Sat, 20 Jul 2019 11:11:54 -0700
Solely relying on a relation's reltuples/relpages estimate to size the
Bloom filters used by amcheck verification makes verification less
effective when the estimates are very stale. In extreme cases,
verification options that use Bloom filters internally could be totally
ineffective, without users receiving any clear indication that certain
types of corruption might easily be missed.
To fix, use RelationGetNumberOfBlocks() instead of relpages to size the
downlink block Bloom filter. Use the same RelationGetNumberOfBlocks()
value to derive a minimum size for the heapallindexed Bloom filter,
rather than completely trusting reltuples. Verification will still be
reasonably effective when the projected/estimated number of Bloom filter
elements is at least 1/5 of the final number of elements, which is
assured by the new sizing logic.
Reported-By: Alexander Korotkov
Discussion: https://postgr.es/m/CAH2-Wzk0ke2J42KrNYBKu0Xovjy-sU5ub7PWjgpbsKdAQcL4OA@mail.gmail.com
Backpatch: 11-, where downlink/heapallindexed verification were added.
M contrib/amcheck/verify_nbtree.c
Use column collation for extended statistics
commit : 5a8ee9f2dbe040b9a0cb7f73a4376633f93b4ab4
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Thu, 18 Jul 2019 12:28:16 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Thu, 18 Jul 2019 12:28:16 +0200
The current extended statistics code was a bit confused which collation
to use. When building the statistics, the collations defined as default
for the data types were used (since commit 5e0928005). The MCV code was
however using the column collations for MCV serialization, and then
DEFAULT_COLLATION_OID when computing estimates. So overall the code was
using all three possible options, inconsistently.
This uses the column colation everywhere - this makes it consistent with
what 5e0928005 did for regular stats. We however do not track the
collations in a catalog, because we can derive them from column-level
information. This may need to change in the future, e.g. after allowing
statistics on expressions.
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu
Backpatch-to: 12
M src/backend/commands/statscmds.c
M src/backend/statistics/dependencies.c
M src/backend/statistics/mcv.c
M src/backend/statistics/mvdistinct.c
Rework examine_opclause_expression to use varonleft
commit : fc4faea17971a927daf936a4b17564140ee412f6
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Fri, 19 Jul 2019 16:28:28 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Fri, 19 Jul 2019 16:28:28 +0200
The examine_opclause_expression function needs to return information on
which side of the operator we found the Var, but the variable was called
"isgt" which is rather misleading (it assumes the operator is either
less-than or greater-than, but it may be equality or something else).
Other places in the planner use a variable called "varonleft" for this
purpose, so just adopt the same convention here.
The code also assumed we don't care about this flag for equality, as
(Var = Const) and (Const = Var) should be the same thing. But that does
not work for cross-type operators, in which case we need to pass the
parameters to the procedure in the right order. So just use the same
code for all types of expressions.
This means we don't need to care about the selectivity estimation
function anymore, at least not in this code. We should only get the
supported cases here (thanks to statext_is_compatible_clause).
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu
Backpatch-to: 12
M src/backend/statistics/extended_stats.c
M src/backend/statistics/mcv.c
M src/include/statistics/extended_stats_internal.h
Silence compiler warning, hopefully.
commit : 533522846ba050efe9df740e5916ced87144c8f2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 19 Jul 2019 14:48:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 19 Jul 2019 14:48:57 -0400
Absorb commit e5e04c962a5d12eebbf867ca25905b3ccc34cbe0 from upstream
IANA code, in hopes of silencing warnings from MSVC about negating
a bool value.
Discussion: https://postgr.es/m/20190719035347.GJ1859@paquier.xyz
M src/timezone/zic.c
Doc: clarify when table rewrites happen with column addition and DEFAULT
commit : b990cc38dc64f3333c1c61aba247bfbaea1475f8
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 19 Jul 2019 11:43:05 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 19 Jul 2019 11:43:05 +0900
16828d5 has improved ALTER TABLE so as a column addition does not
require a rewrite for a non-NULL default with constant expressions, but
one spot in the documentation did not get updated consistently.
The documentation also now clarifies the fact that this does not apply
if the expression is volatile, where a table rewrite is still required.
Reported-by: Daniel Westermann
Author: Ian Barwick
Reviewed-by: Michael Paquier, Daniel Westermann
Discussion: https://postgr.es/m/DB6PR0902MB2184C7D5645CF15D75EB7957D2CF0@DB6PR0902MB2184.eurprd09.prod.outlook.com
Backpatch-through: 11
M doc/src/sgml/ddl.sgml
Fix error in commit e6feef57.
commit : 5245552ddbc43b7705389cae9c5095e687a3c950
author : Jeff Davis <jdavis@postgresql.org>
date : Thu, 18 Jul 2019 17:26:56 -0700
committer: Jeff Davis <jdavis@postgresql.org>
date : Thu, 18 Jul 2019 17:26:56 -0700
I was careless passing a datum directly to DATE_NOT_FINITE without
calling DatumGetDateADT() first.
Backpatch-through: 9.4
M src/backend/utils/adt/rangetypes.c
Fix daterange canonicalization for +/- infinity.
commit : 613eabcd51c3adec50e28c1f151d574db5a05a9e
author : Jeff Davis <jdavis@postgresql.org>
date : Thu, 18 Jul 2019 17:26:47 -0700
committer: Jeff Davis <jdavis@postgresql.org>
date : Thu, 18 Jul 2019 17:26:47 -0700
The values 'infinity' and '-infinity' are a part of the DATE type
itself, so a bound of the date 'infinity' is not the same as an
unbounded/infinite range. However, it is still wrong to try to
canonicalize such values, because adding or subtracting one has no
effect. Fix by treating 'infinity' and '-infinity' the same as
unbounded ranges for the purposes of canonicalization (but not other
purposes).
Backpatch to all versions because it is inconsistent with the
documented behavior. Note that this could be an incompatibility for
applications relying on the behavior contrary to the documentation.
Author: Laurenz Albe
Reviewed-by: Thomas Munro
Discussion: https://postgr.es/m/77f24ea19ab802bc9bc60ddbb8977ee2d646aec1.camel%40cybertec.at
Backpatch-through: 9.4
M src/backend/utils/adt/rangetypes.c
M src/test/regress/expected/rangetypes.out
M src/test/regress/sql/rangetypes.sql
Fix nbtree metapage cache upgrade bug.
commit : 7772dece98506233f40c6751e5adb7983a0c1635
author : Peter Geoghegan <pg@bowt.ie>
date : Thu, 18 Jul 2019 13:22:54 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Thu, 18 Jul 2019 13:22:54 -0700
Commit 857f9c36cda, which taught nbtree VACUUM to avoid unnecessary
index scans, bumped the nbtree version number from 2 to 3, while adding
the ability for nbtree indexes to be upgraded on-the-fly. Various
assertions that assumed that an nbtree index was always on version 2 had
to be changed to accept any supported version (version 2 or 3 on
Postgres 11).
However, a few assertions were missed in the initial commit, all of
which were in code paths that cache a local copy of the metapage
metadata, where the index had been expected to be on the current version
(no longer version 2) as a generic sanity check. Rather than simply
update the assertions, follow-up commit 0a64b45152b intentionally made
the metapage caching code update the per-backend cached metadata version
without changing the on-disk version at the same time. This could even
happen when the planner needed to determine the height of a B-Tree for
costing purposes. The assertions only fail on Postgres v12 when
upgrading from v10, because they were adjusted to use the authoritative
shared memory metapage by v12's commit dd299df8.
To fix, remove the cache-only upgrade mechanism entirely, and update the
assertions themselves to accept any supported version (go back to using
the cached version in v12). The fix is almost a full revert of commit
0a64b45152b on the v11 branch.
VACUUM only considers the authoritative metapage, and never bothers with
a locally cached version, whereas everywhere else isn't interested in
the metapage fields that were added by commit 857f9c36cda. It seems
unlikely that this bug has affected any user on v11.
Reported-By: Christoph Berg
Bug: #15896
Discussion: https://postgr.es/m/15896-5b25e260fdb0b081%40postgresql.org
Backpatch: 11-, where VACUUM was taught to avoid unnecessary index scans.
M src/backend/access/nbtree/nbtpage.c
M src/backend/access/nbtree/nbtxlog.c
M src/include/access/nbtree.h
Simplify bitmap updates in multivariate MCV code
commit : 79d3a1e52a3c1706cbabb00aec9175da7055319d
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Wed, 17 Jul 2019 18:16:50 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Wed, 17 Jul 2019 18:16:50 +0200
When evaluating clauses on a multivariate MCV list, we build a bitmap
tracking how the clauses match each item of the MCV list. When updating
the bitmap we need to consider the current value (tracking how the item
matches preceding clauses), match for the current clause and whether the
clauses are connected by AND or OR.
Until now the logic was copied on every place updating the bitmap, which
was not quite readable. So just move it to a separate function and call
it where needed.
Backpatch to 12, where the code was introduced. While not a bugfix, this
should make maintenance and future backpatches easier.
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu
M src/backend/statistics/mcv.c
Fix handling of NULLs in MCV items and constants
commit : 1c2acc32dc6cb15c6ea038a954af9a4db8d01f08
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Mon, 15 Jul 2019 02:00:31 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Mon, 15 Jul 2019 02:00:31 +0200
There were two issues in how the extended statistics handled NULL values
in opclauses. Firstly, the code was oblivious to the possibility that
Const may be NULL (constisnull=true) in which case the constvalue is
undefined. We need to treat this as a mismatch, and not call the proc.
Secondly, the MCV item itself may contain NULL values too - the code
already did check that, and updated the match bitmap accordingly, but
failed to ensure we won't call the operator procedure anyway. It did
work for AND-clauses, because in that case false in the bitmap stops
evaluation of further clauses. But for OR-clauses ir was not easy to
get incorrect estimates or even trigger a crash.
This fixes both issues by extending the existing check so that it looks
at constisnull too, and making sure it skips calling the procedure.
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu
M src/backend/statistics/mcv.c
M src/test/regress/expected/stats_ext.out
M src/test/regress/sql/stats_ext.sql
Fix handling of opclauses in extended statistics
commit : 42276976a1437c88fb6176fc1a876fd79a139eb0
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Sat, 13 Jul 2019 00:12:16 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Sat, 13 Jul 2019 00:12:16 +0200
We expect opclauses to have exactly one Var and one Const, but the code
was checking the Const by calling is_pseudo_constant_clause() which is
incorrect - we need a proper constant.
Fixed by using plain IsA(x,Const) to check type of the node. We need to
do these checks in two places, so move it into a separate function that
can be called in both places.
Reported by Andreas Seltenreich, based on crash reported by sqlsmith.
Backpatch to v12, where this code was introduced.
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu
Backpatch-to: 12
M src/backend/statistics/extended_stats.c
M src/backend/statistics/mcv.c
M src/include/statistics/extended_stats_internal.h
Remove unnecessary TYPECACHE_GT_OPR lookup
commit : 3944e855bc5bee32d99a9ba2245a026d4bafe282
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Wed, 17 Jul 2019 18:13:39 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Wed, 17 Jul 2019 18:13:39 +0200
The TYPECACHE_GT_OPR is not needed (it used to be in older version of
the MCV code), but the compiler failed to detect this as the result was
used in a fmgr_info() call, populating a FmgrInfo entry.
Backpatch to v12, where this code was introduced.
Discussion: https://postgr.es/m/8736jdhbhc.fsf%40ansel.ydns.eu
Backpatch-to: 12
M src/backend/statistics/mcv.c
tableam: comment improvements.
commit : fa7bb9345370ab69cac24b7213262f36567d9c9c
author : Andres Freund <andres@anarazel.de>
date : Wed, 17 Jul 2019 19:39:54 -0700
committer: Andres Freund <andres@anarazel.de>
date : Wed, 17 Jul 2019 19:39:54 -0700
Author: Brad DeJong
Discussion: https://postgr.es/m/CAJnrtnxDYOQFsDfWz2iri0T_fFL2ZbbzgCOE=4yaMcszgcsf4A@mail.gmail.com
Backpatch: 12-
M src/include/access/tableam.h
Simplify description of --data-checksums in documentation of initdb
commit : 4ed6001d7889f534e052e67e39acc2eb477fc645
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 18 Jul 2019 10:06:50 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 18 Jul 2019 10:06:50 +0900
The documentation mentioned that data checksums cannot be changed after
initialization, which is not true as pg_checksums can do that with its
--enable option introduced in v12. This simply removes the sentence
telling so.
Reported-by: Basil Bourque
Author: Michael Paquier
Reviewed-by: Daniel Gustafsson
Discussion: https://postgr.es/m/15909-e9d74271f1647472@postgresql.org
Backpatch-through: 12
M doc/src/sgml/ref/initdb.sgml
Update time zone data files to tzdata release 2019b.
commit : d4f283162e8d09ca39085b2745e99543990e1d06
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 17 Jul 2019 19:15:21 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 17 Jul 2019 19:15:21 -0400
Brazil no longer observes DST.
Historical corrections for Palestine, Hong Kong, and Italy.
M src/timezone/data/tzdata.zi
Sync our copy of the timezone library with IANA release tzcode2019b.
commit : 59cea8f36be725533a0f94607f498b7628aa4b9d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 17 Jul 2019 18:26:23 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 17 Jul 2019 18:26:23 -0400
A large fraction of this diff is just due to upstream's somewhat
random decision to rename a bunch of internal variables and struct
fields. However, there is an interesting new feature in zic:
it's grown a "-b slim" option that emits zone files without 32-bit
data and other backwards-compatibility hacks. We should consider
whether we wish to enable that.
M src/timezone/README
M src/timezone/localtime.c
M src/timezone/pgtz.h
M src/timezone/tzfile.h
M src/timezone/zic.c
Fix thinko in construction of old_conpfeqop list.
commit : e0d13dc6fd71cc647af8aaa82179f1b878f41437
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 16 Jul 2019 18:17:47 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 16 Jul 2019 18:17:47 -0400
This should lappend the OIDs, not lcons them; the existing code produced
a list in reversed order. This is harmless for single-key FKs or FKs
where all the key columns are of the same type, which probably explains
how it went unnoticed. But if those conditions are not met,
ATAddForeignKeyConstraint would make the wrong decision about whether an
existing FK needs to be revalidated. I think it would almost always err
in the safe direction by revalidating a constraint that didn't need it.
You could imagine scenarios where the pfeqop check was fooled by
swapping the types of two FK columns in one ALTER TABLE, but that case
would probably be rejected by other tests, so it might be impossible to
get to the worst-case scenario where an FK should be revalidated and
isn't. (And even then, it's likely to be fine, unless there are weird
inconsistencies in the equality behavior of the replacement types.)
However, this is a performance bug at least.
Noted while poking around to see whether lcons calls could be converted
to lappend.
This bug is old, dating to commit cb3a7c2b9, so back-patch to all
supported branches.
M src/backend/commands/tablecmds.c
doc: Fix Tamil language mention in PG 12 docs
commit : 178ca6b26c3d59ff330b229f11fca89001749ea1
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 15 Jul 2019 21:18:49 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 15 Jul 2019 21:18:49 -0400
Reported-by: John Naylor
Discussion: https://postgr.es/m/CACPNZCs2c7yLGKhtcL=h9OmZdwQQDshFs9Bxypo=Fc5b0TVsMQ@mail.gmail.com
Backpatch-through: 12
M doc/src/sgml/release-12.sgml
doc: mention pg_reload_conf() for reloading the config file
commit : d116ebca6ccc3712dadd024be3d14852c7e03984
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 15 Jul 2019 20:57:24 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 15 Jul 2019 20:57:24 -0400
Reported-by: Ian Barwick
Discussion: https://postgr.es/m/538950ec-b86a-1650-6078-beb7091c09c2@2ndquadrant.com
Backpatch-through: 9.4
M doc/src/sgml/client-auth.sgml
Correct nbtsplitloc.c comment.
commit : ac37bd51a4227683529f37148d6aefc95c837abb
author : Peter Geoghegan <pg@bowt.ie>
date : Mon, 15 Jul 2019 14:35:05 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Mon, 15 Jul 2019 14:35:05 -0700
The logic just added by commit e3899ffd falls back on a 50:50 page split
in the event of a new item that's just to the right of our provisional
"many duplicates" split point. Fix a comment that incorrectly claimed
that the new item had to be just to the left of our provisional split
point.
Backpatch: 12-, just like commit e3899ffd.
M src/backend/access/nbtree/nbtsplitloc.c
Fix pathological nbtree split point choice issue.
commit : 2f23453e492955c32d952bc1cff651e66657d32b
author : Peter Geoghegan <pg@bowt.ie>
date : Mon, 15 Jul 2019 13:19:12 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Mon, 15 Jul 2019 13:19:12 -0700
Specific ever-decreasing insertion patterns could cause successive
unbalanced nbtree page splits. Problem cases involve a large group of
duplicates to the left, and ever-decreasing insertions to the right.
To fix, detect the situation by considering the newitem offset before
performing a split using nbtsplitloc.c's "many duplicates" strategy. If
the new item was inserted just to the right of our provisional "many
duplicates" split point, infer ever-decreasing insertions and fall back
on a 50:50 (space delta optimal) split. This seems to barely affect
cases that already had acceptable space utilization.
An alternative fix also seems possible. Instead of changing
nbtsplitloc.c split choice logic, we could instead teach _bt_truncate()
to generate a new value for new high keys by interpolating from the
lastleft and firstright key values. That would certainly be a more
elegant fix, but it isn't suitable for backpatching.
Discussion: https://postgr.es/m/CAH2-WznCNvhZpxa__GqAa1fgQ9uYdVc=_apArkW2nc-K3O7_NA@mail.gmail.com
Backpatch: 12-, where the nbtree page split enhancements were introduced.
M src/backend/access/nbtree/nbtsplitloc.c
Fix documentation for pgbench tpcb-like.
commit : dd5e47a92cfce52e3e35233a33b190ea498eed84
author : Thomas Munro <tmunro@postgresql.org>
date : Sun, 14 Jul 2019 14:19:54 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Sun, 14 Jul 2019 14:19:54 +1200
We choose a random value for delta, not balance. Back-patch to 9.6 where
the mistake arrived.
Author: Fabien Coelho
Discussion: https://postgr.es/m/alpine.DEB.2.21.1904081752210.5867@lancre
M doc/src/sgml/ref/pgbench.sgml
Revive test of concurrent OID generation.
commit : dffb891d78cb0db0db010c2f263b8cff72e03aaa
author : Noah Misch <noah@leadboat.com>
date : Sat, 13 Jul 2019 13:34:22 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sat, 13 Jul 2019 13:34:22 -0700
Commit 578b229718e8f15fa779e20f086c4b6bb3776106 replaced it with a
concurrent "nextval" test. That version does not detect PostgreSQL's
incompatibility with xlc 13.1.3, so bring back an OID-based test that
does. Back-patch to v12, where that commit first appeared.
Discussion: https://postgr.es/m/20190707170035.GA1485546@rfd.leadboat.com
M src/bin/pgbench/t/001_pgbench_with_server.pl
Fix and improve several places in the docs
commit : de14e54d7bd71f9256aae08dec832af25da3fd35
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 13 Jul 2019 14:43:48 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 13 Jul 2019 14:43:48 +0900
This adds some missing markups, fixes a couple of incorrect ones and
clarifies some documentation in various places.
Author: Liudmila Mantrova
Discussion: https://postgr.es/m/a068f947-7a51-5df1-b3fd-1a131ae5c044@postgrespro.ru
Backpatch-through: 12
M doc/src/sgml/backup.sgml
M doc/src/sgml/biblio.sgml
M doc/src/sgml/ref/alter_foreign_table.sgml
M doc/src/sgml/ref/pg_checksums.sgml
M doc/src/sgml/ref/pg_dump.sgml
M doc/src/sgml/ref/pg_rewind.sgml
M doc/src/sgml/ref/pgbench.sgml
M doc/src/sgml/ref/reindex.sgml
Fix get_actual_variable_range() to cope with broken HOT chains.
commit : cee976c4e8c4d97286a015ab54aa859faf839b54
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 12 Jul 2019 16:24:59 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 12 Jul 2019 16:24:59 -0400
Commit 3ca930fc3 modified get_actual_variable_range() to use a new
"SnapshotNonVacuumable" snapshot type for selecting tuples that it
would consider valid. However, because that snapshot type can accept
recently-dead tuples, this caused a bug when using a recently-created
index: we might accept a recently-dead tuple that is an early member
of a broken HOT chain and does not actually match the index entry.
Then, the data extracted from the heap tuple would not necessarily be
an endpoint value of the column; it could even be NULL, leading to
get_actual_variable_range() itself reporting "found unexpected null
value in index". Even without an error, this could lead to poor
plan choices due to an erroneous notion of the endpoint value.
We can improve matters by changing the code to use the index-only
scan technique (which didn't exist when get_actual_variable_range was
originally written). If any of the tuples in a HOT chain are live
enough to satisfy SnapshotNonVacuumable, we take the data from the
index entry, ignoring what is in the heap. This fixes the problem
without changing the live-vs-dead-tuple behavior from what was
intended by commit 3ca930fc3.
A side benefit is that for static tables we might not have to touch
the heap at all (when the extremal value is in an all-visible page).
In addition, we can save some overhead by not having to create a
complete ExecutorState, and we don't need to run FormIndexDatum,
avoiding more cycles as well as the possibility of failure for
indexes on expressions. (I'm not sure that this code would ever
be used to determine the extreme value of an expression, in the
current state of the planner; but it's definitely possible that
lower-order columns of the selected index could be expressions.
So one could construct perhaps-artificial examples in which the
old code unexpectedly failed due to trying to compute an
expression's value for a now-dead row.)
Per report from Manuel Rigger. Back-patch to v11 where commit
3ca930fc3 came in.
Discussion: https://postgr.es/m/CA+u7OA7W4NWEhCvftdV6_8bbm2vgypi5nuxfnSEJQqVKFSUoMg@mail.gmail.com
M src/backend/utils/adt/selfuncs.c
Fix RANGE partition pruning with multiple boolean partition keys
commit : 30a268ed2e2944b3902d3e10a9876e498a0c12b9
author : David Rowley <drowley@postgresql.org>
date : Fri, 12 Jul 2019 19:11:45 +1200
committer: David Rowley <drowley@postgresql.org>
date : Fri, 12 Jul 2019 19:11:45 +1200
match_clause_to_partition_key incorrectly would return
PARTCLAUSE_UNSUPPORTED if a bool qual could not be matched to the current
partition key. This was a problem, as it causes the calling function to
discard the qual and not try to match it to any other partition key. If
there was another partition key which did match this qual, then the qual
would not be checked again and we could fail to prune some partitions.
The worst this could do was to cause partitions not to be pruned when they
could have been, so there was no danger of incorrect query results here.
Fix this by changing match_boolean_partition_clause to have it return a
PartClauseMatchStatus rather than a boolean value. This allows it to
communicate if the qual is unsupported or if it just does not match this
particular partition key, previously these two cases were treated the
same. Now, if match_clause_to_partition_key is unable to match the qual
to any other qual type then we can simply return the value from the
match_boolean_partition_clause call so that the calling function properly
treats the qual as either unmatched or unsupported.
Reported-by: Rares Salcudean
Reviewed-by: Amit Langote
Backpatch-through: 11 where partition pruning was introduced
Discussion: https://postgr.es/m/CAHp_FN2xwEznH6oyS0hNTuUUZKp5PvegcVv=Co6nBXJ+mC7Y5w@mail.gmail.com
M src/backend/partitioning/partprune.c
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql
Fixes for jsonpath filter expression elements table in docs
commit : 1ed89826b82c693c311d9974f3f3138013f1b929
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Thu, 11 Jul 2019 18:18:15 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Thu, 11 Jul 2019 18:18:15 +0300
Reported-by: Thom Brown
Discussion: https://postgr.es/m/CAA-aLv4Tggy6Z3kaG9n%2B3SHwOVGN2Yj_MJXfdfwjH_jBNZzJNA%40mail.gmail.com
Backpatch-through: 12
M doc/src/sgml/func.sgml
docs: remove pg_roles mention of the oid column being displayed
commit : ff597b656febe152b1650fc5619e57fbd1364c2c
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 10 Jul 2019 14:24:36 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 10 Jul 2019 14:24:36 -0400
It is now always displayed in PG 12+.
Discussion: https://postgr.es/m/b6ec6167-5dd5-6347-ac1d-1fd49382019f@2ndquadrant.com
Author: Ian Barwick
Backpatch-through: 12
M doc/src/sgml/catalogs.sgml
Mention limitation of unique in partitioned tables
commit : 220857a87508fdac3fd4caf5f344a8fe9e70702d
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 10 Jul 2019 08:58:41 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 10 Jul 2019 08:58:41 -0400
Per gripe from Phil Bayer.
Authors: Amit Langote and others
Discussion: https://postgr.es/m/156236160709.1192.4498528196556144085@wrigleys.postgresql.org
M doc/src/sgml/ddl.sgml
Assorted fixes for jsonpath documentation
commit : a5c2f3a346fcda21d3dc9227b2c07854a7973729
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Wed, 10 Jul 2019 15:43:53 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Wed, 10 Jul 2019 15:43:53 +0300
This commit contains assorted fixes for jsonpath documentation including:
grammar fixes, incorrect examples fixes as well as wording improvements.
Discussion: https://postgr.es/m/CAA-aLv4VVX%3Db9RK5hkfPXJczqaiTdqO04teW9i0wiQVhdKcqzw%40mail.gmail.com
Author: Liudmila Mantrova
Reviewed-by: Alexander Korotkov
Reported-by: Thom Brown
Backpatch-through: 12
M doc/src/sgml/func.sgml
M doc/src/sgml/json.sgml
Fix variable initialization when using buffering build with GiST
commit : 4d713595914beb705539ca5cd09c8b3a95f65c70
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 10 Jul 2019 15:15:03 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 10 Jul 2019 15:15:03 +0900
This can cause valgrind to complain, as the flag marking a buffer as a
temporary copy was not getting initialized.
While on it, fill in with zeros newly-created buffer pages. This does
not matter when loading a block from a temporary file, but it makes the
push of an index tuple into a new buffer page safer.
This has been introduced by 1d27dcf, so backpatch all the way down to
9.4.
Author: Alexander Lakhin
Discussion: https://postgr.es/m/15899-0d24fb273b3dd90c@postgresql.org
Backpatch-through: 9.4
M src/backend/access/gist/gistbuildbuffers.c
Fix missing calls to table_finish_bulk_insert during COPY, take 2
commit : b8ef33b2d14519da0d038e9d63f51a6714ef764a
author : David Rowley <drowley@postgresql.org>
date : Wed, 10 Jul 2019 16:02:18 +1200
committer: David Rowley <drowley@postgresql.org>
date : Wed, 10 Jul 2019 16:02:18 +1200
86b85044e abstracted calls to heap functions in COPY FROM to support a
generic table AM. However, when performing a copy into a partitioned
table, this commit neglected to call table_finish_bulk_insert for each
partition. Before 86b85044e, when we always called the heap functions,
there was no need to call heapam_finish_bulk_insert for partitions since
it only did any work when performing a copy without WAL. For partitioned
tables, this was unsupported anyway, so there was no issue. With
pluggable storage, we can't make any assumptions about what the table AM
might want to do in its equivalent function, so we'd better ensure we
always call table_finish_bulk_insert each partition that's received a row.
For now, we make the table_finish_bulk_insert call whenever we evict a
CopyMultiInsertBuffer out of the CopyMultiInsertInfo. This does mean
that it's possible that we call table_finish_bulk_insert multiple times
per partition, which is not a problem other than being an inefficiency.
Improving this requires a more invasive patch, so let's leave that for
another day.
This also changes things so that we no longer needlessly call
table_finish_bulk_insert when performing a COPY FROM for a non-partitioned
table when not using multi-inserts.
Reported-by: Robert Haas
Backpatch-through: 12
Discussion: https://postgr.es/m/CA+TgmoYK=6BpxiJ0tN-p9wtH0BTAfbdxzHhwou0mdud4+BkYuQ@mail.gmail.com
M src/backend/commands/copy.c
Fix few typos and minor word smithing in tableam comments.
commit : e33a1435be55f1f9aecff0337ed96f7e5092b146
author : Amit Kapila <akapila@postgresql.org>
date : Wed, 10 Jul 2019 07:59:51 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Wed, 10 Jul 2019 07:59:51 +0530
Reported-by: Ashwin Agrawal
Author: Ashwin Agrawal
Reviewed-by: Amit Kapila
Backpatch-through: 12, where it was introduced
Discussion: https://postgr.es/m/CALfoeisgdZhYDrJOukaBzvXfJOK2FQ0szVMK7dzmcy6w93iDUA@mail.gmail.com
M src/include/access/tableam.h
Pass QueryEnvironment down to EvalPlanQual's EState.
commit : abbb2e14321313374c5fff3d3ecb626d98ee353e
author : Thomas Munro <tmunro@postgresql.org>
date : Wed, 10 Jul 2019 10:15:43 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Wed, 10 Jul 2019 10:15:43 +1200
Otherwise the executor can't see trigger transition tables during
EPQ evaluation. Fixes bug #15900 and almost certainly also #15720.
Back-patch to 10, where trigger transition tables landed.
Author: Alex Aktsipetrov
Reviewed-by: Thomas Munro, Tom Lane
Discussion: https://postgr.es/m/15900-bc482754fe8d7415%40postgresql.org
Discussion: https://postgr.es/m/15720-38c2b29e5d720187%40postgresql.org
M src/backend/executor/execMain.c
Propagate trigger arguments to partitions
commit : ae0a2945b45ce63b7945284a7ddbb3e1c286fe95
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 9 Jul 2019 17:16:36 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 9 Jul 2019 17:16:36 -0400
We were creating the cloned triggers with an empty list of arguments,
losing the ones that had been specified by the user when creating the
trigger in the partitioned table. Repair.
This was forgotten in commit 86f575948c77.
Author: Patrick McHardy
Reviewed-by: Tomas Vondra
Discussion: https://postgr.es/m/20190709130027.amr2cavjvo7rdvac@access1.trash.net
Discussion: https://postgr.es/m/15752-123bc90287986de4@postgresql.org
M src/backend/commands/tablecmds.c
M src/backend/commands/trigger.c
M src/test/regress/expected/triggers.out
M src/test/regress/sql/triggers.sql
Message style improvements
commit : 48d6d5a2afa59c4cf83cad6719cbbf298ef27c08
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 9 Jul 2019 15:47:09 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 9 Jul 2019 15:47:09 +0200
M src/bin/initdb/initdb.c
M src/bin/pg_basebackup/pg_recvlogical.c
M src/bin/pg_checksums/pg_checksums.c
M src/bin/pg_dump/pg_backup_db.c
M src/bin/pg_dump/pg_dumpall.c
M src/bin/pg_upgrade/option.c
Force hash joins to be enabled in the hash join regression tests.
commit : 5526baf54902a56c5bc1b4abe625acb33d7357bf
author : Thomas Munro <tmunro@postgresql.org>
date : Tue, 9 Jul 2019 18:11:01 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Tue, 9 Jul 2019 18:11:01 +1200
Otherwise the regressplans.sh tests generate extremely slow nested
loop joins. Back-patch to 11 where the hash join tests came in.
Reported-by: Michael Paquier
Discussion: https://postgr.es/m/20190708055256.GB2709%40paquier.xyz
M src/test/regress/expected/join_hash.out
M src/test/regress/sql/join_hash.sql
doc: adjust to_timestamp()/to_date() wording
commit : d0217d5ef2b8c44fa786f7f96c514684a0a04b28
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 8 Jul 2019 23:04:02 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 8 Jul 2019 23:04:02 -0400
Discussion: https://postgr.es/m/20190706202425.GA16933@telsasoft.com
Author: Justin Pryzby
Backpatch-through: 12
M doc/src/sgml/func.sgml
doc: Clarify logical replication documentation
commit : 0d67263563517131c5cf9ba6df46fc2541bc7d9e
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 8 Jul 2019 14:28:42 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 8 Jul 2019 14:28:42 +0200
Document that the data types of replicated tables do not need to
match. The documentation previously claimed that they had to match.
Author: Robert Treat <rob@xzilla.net>
Discussion: https://www.postgresql.org/message-id/flat/CAJSLCQ13==D8Ka2YLyctTm0Y+8MhGYcX_zj7fU0rqRzhcV++3w@mail.gmail.com
M doc/src/sgml/logical-replication.sgml
Fix small memory leak in ecpglib ecpg_update_declare_statement() is called the second time.
commit : 58006f8041fffc9260b92fc2cb3a571aaa6c6d22
author : Michael Meskes <meskes@postgresql.org>
date : Tue, 2 Jul 2019 03:51:13 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Tue, 2 Jul 2019 03:51:13 +0200
Author: "Zhang, Jie" <zhangjie2@cn.fujitsu.com>
M src/interfaces/ecpg/ecpglib/prepare.c
In pg_log_generic(), be more paranoid about preserving errno.
commit : cf665ad4c89eb9b20285dc04aec906d46ed810d2
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 6 Jul 2019 11:25:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 6 Jul 2019 11:25:37 -0400
This code failed to account for the possibility that malloc() would
change errno, resulting in wrong output for %m, not to mention the
possibility of message truncation. Such a change is obviously
expected when malloc fails, but there's reason to fear that on some
platforms even a successful malloc call can modify errno.
Discussion: https://postgr.es/m/2576.1527382833@sss.pgh.pa.us
M src/common/logging.c
Add missing source files to nls.mk
commit : c8e0997239840888a974624b0ab020177357f0ae
author : Peter Eisentraut <peter@eisentraut.org>
date : Sat, 6 Jul 2019 15:02:53 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sat, 6 Jul 2019 15:02:53 +0200
M src/interfaces/ecpg/ecpglib/nls.mk
M src/interfaces/libpq/nls.mk
psql: Fix logging output format
commit : d8ec5ebaea4455a5b19fa1bc8ec6eb299e93e835
author : Peter Eisentraut <peter@eisentraut.org>
date : Sat, 6 Jul 2019 14:58:08 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sat, 6 Jul 2019 14:58:08 +0200
In normal interactive mode, psql's log messages accidentally got a
"psql:" prefix that was not supposed to be there. This only happened
if there was no .psqlrc file being read, so it wasn't discovered for a
while. Fix this by adding the appropriate logging format
configuration call in the right code path.
Discussion: https://www.postgresql.org/message-id/7586.1560540361@sss.pgh.pa.us
M src/bin/psql/startup.c
Add missing assertions for required table am callbacks.
commit : e5eba10d79bd8d919a5e8594d809cd99abd09f01
author : Amit Kapila <akapila@postgresql.org>
date : Sat, 6 Jul 2019 11:45:39 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Sat, 6 Jul 2019 11:45:39 +0530
Reported-by: Ashwin Agrawal
Author: Ashwin Agrawal
Reviewed-by: Amit Kapila
Backpatch-through: 12, where it was introduced
Discussion: https://postgr.es/m/CALfoeisgdZhYDrJOukaBzvXfJOK2FQ0szVMK7dzmcy6w93iDUA@mail.gmail.com
M src/backend/access/table/tableamapi.c
Remove unused variable in statext_mcv_serialize()
commit : a5dc37866add6552834ec5af6a0053f521fbcc62
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Fri, 5 Jul 2019 18:06:02 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Fri, 5 Jul 2019 18:06:02 +0200
The itemlen variable used to be referenced in multiple places, but since
reworking the serialization code it's used only in one assert. Fixed by
removing the variable and calling the macro from the assert directly.
Backpatch to 12, where this code was introduced.
Reported-by: Jeff Janes
Discussion: https://postgr.es/m/CAMkU=1zc_ovH9NZd_9ovuiEWkF9yX06URUDdXCmgDydf-bqB5A@mail.gmail.com
M src/backend/statistics/mcv.c
Simplify pg_mcv_list (de)serialization
commit : e74d141d0d97a7a9f059cdb3cd91ff52599a629b
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Fri, 5 Jul 2019 00:45:20 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Fri, 5 Jul 2019 00:45:20 +0200
The serialization format of multivariate MCV lists included alignment in
order to allow direct access to part of the serialized data, but despite
multiple fixes (see for example commits d85e0f366a and ea4e1c0e8f) this
proved to be problematic.
This commit abandons alignment in the serialized format, and just copies
everything during deserialization. We now also track amount of memory
needed after deserialization (including alignment), which allows us to
deserialize the MCV list in a single pass.
Bump catversion, as this affects contents of pg_statistic_ext_data.
Backpatch to 12, where multi-column MCV lists were introduced.
Author: Tomas Vondra
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/2201.1561521148@sss.pgh.pa.us
M src/backend/statistics/mcv.c
M src/include/catalog/catversion.h
M src/include/statistics/extended_stats_internal.h
Fix pg_mcv_list_items() to produce text[]
commit : cc052b423ad7dc92abb3461a096408c3997c36e1
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Thu, 4 Jul 2019 23:43:04 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Thu, 4 Jul 2019 23:43:04 +0200
The function pg_mcv_list_items() returns values stored in MCV items. The
items may contain columns with different data types, so the function was
generating text array-like representation, but in an ad-hoc way without
properly escaping various characters etc.
Fixed by simply building a text[] array, which also makes it easier to
use from queries etc.
Requires changes to pg_proc entry, so bump catversion.
Backpatch to 12, where multi-column MCV lists were introduced.
Author: Tomas Vondra
Reviewed-by: Dean Rasheed
Discussion: https://postgr.es/m/20190618205920.qtlzcu73whfpfqne@development
M src/backend/statistics/mcv.c
M src/include/catalog/catversion.h
M src/include/catalog/pg_proc.dat
M src/test/regress/expected/stats_ext.out
Speed-up build of MCV lists with many distinct values
commit : 57f459cf6c48e78aa321ac88418815fc65197517
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Thu, 4 Jul 2019 23:02:02 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Thu, 4 Jul 2019 23:02:02 +0200
When building multi-column MCV lists, we compute base frequency for each
item, i.e. a product of per-column frequencies for values from the item.
As a value may be in multiple groups, the code was scanning the whole
array of groups while adding items to the MCV list. This works fine as
long as the number of distinct groups is small, but it's easy to trigger
trigger O(N^2) behavior, especially after increasing statistics target.
This commit precomputes frequencies for values in all columns, so that
when computing the base frequency it's enough to make a simple bsearch
lookup in the array.
Backpatch to 12, where multi-column MCV lists were introduced.
Discussion: https://postgr.es/m/20190618205920.qtlzcu73whfpfqne@development
M src/backend/statistics/mcv.c
doc: Spell checking
commit : 1970da1a0a7e9793d1676341fcb0c9a01f3db0dc
author : Peter Eisentraut <peter@eisentraut.org>
date : Fri, 5 Jul 2019 08:33:51 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Fri, 5 Jul 2019 08:33:51 +0200
M doc/src/sgml/btree.sgml
M doc/src/sgml/client-auth.sgml
M doc/src/sgml/config.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/gin.sgml
M doc/src/sgml/json.sgml
M doc/src/sgml/release-12.sgml
M doc/src/sgml/spgist.sgml
M doc/src/sgml/xfunc.sgml
Ensure plpgsql result tuples have the right composite type marking.
commit : 1dd8cf1b46a2e4ef68fc39771c21b8b737cf58b1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 3 Jul 2019 18:08:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 3 Jul 2019 18:08:53 -0400
A function that is declared to return a named composite type must
return tuple datums that are physically marked as having that type.
The plpgsql code path that allowed directly returning an expanded-record
datum forgot to check that, so that an expanded record marked as type
RECORDOID could be returned if it had a physically-compatible tupdesc.
This'd be harmless, I think, if the record value never escaped the
current session --- but it's possible for it to get stored into a table,
and then subsequent sessions can't interpret the anonymous record type.
Fix by flattening the record into a tuple datum and overwriting its
type/typmod fields, if its declared type doesn't match the function's
declared type. (In principle it might be possible to just change the
expanded record's stored type ID info, but there are enough tricky
consequences that I didn't want to mess with that, especially not in
a back-patched bug fix.)
Per bug report from Steve Rogerson. Back-patch to v11 where the bug
was introduced.
Discussion: https://postgr.es/m/cbaecae6-7b87-584e-45f6-4d047b92ca2a@yewtc.demon.co.uk
M src/pl/plpgsql/src/expected/plpgsql_record.out
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpgsql/src/sql/plpgsql_record.sql
Don't remove surplus columns from GROUP BY for inheritance parents
commit : 0cce43a716b40c555892b1d22b41d390ef524ec8
author : David Rowley <drowley@postgresql.org>
date : Wed, 3 Jul 2019 23:45:25 +1200
committer: David Rowley <drowley@postgresql.org>
date : Wed, 3 Jul 2019 23:45:25 +1200
d4c3a156c added code to remove columns that were not part of a table's
PRIMARY KEY constraint from the GROUP BY clause when all the primary key
columns were present in the group by. This is fine to do since we know
that there will only be one row per group coming from this relation.
However, the logic failed to consider inheritance parent relations. These
can have child relations without a primary key, but even if they did, they
could duplicate one of the parent's rows or one from another child
relation. In this case, those additional GROUP BY columns are required.
Fix this by disabling the optimization for inheritance parent tables.
In v11 and beyond, partitioned tables are fine since partitions cannot
overlap and before v11 partitioned tables could not have a primary key.
Reported-by: Manuel Rigger
Discussion: http://postgr.es/m/CA+u7OA7VLKf_vEr6kLF3MnWSA9LToJYncgpNX2tQ-oWzYCBQAw@mail.gmail.com
Backpatch-through: 9.6
M src/backend/optimizer/plan/planner.c
M src/test/regress/expected/aggregates.out
M src/test/regress/sql/aggregates.sql
Add support for Visual Studio 2019 in build scripts
commit : f2d069ce95b13f7ebfc4998ed708e3693166f46d
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 3 Jul 2019 08:57:22 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 3 Jul 2019 08:57:22 +0900
This fixes at the same time a set of inconsistencies in the
documentation and the scripts related to the versions of Windows SDK
supported.
Author: Haribabu Kommi
Reviewed-by: Andrew Dunstan, Juan José Santamaría Flecha, Michael
Paquier
Discussion: https://postgr.es/m/CAJrrPGcfqXhfPyMrny9apoDU7M1t59dzVAvoJ9AeAh5BJi+UzA@mail.gmail.com
Backpatch-through: 9.4
M doc/src/sgml/install-windows.sgml
M src/tools/msvc/MSBuildProject.pm
M src/tools/msvc/README
M src/tools/msvc/Solution.pm
M src/tools/msvc/VSObjectFactory.pm
Fix accidentally swapped error message arguments
commit : 91be5387c20dbd9a015b37064cb789a368974b00
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 2 Jul 2019 23:44:30 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 2 Jul 2019 23:44:30 +0100
Author: Alexey Kondratov <a.kondratov@postgrespro.ru>
M src/bin/initdb/initdb.c
Remove redundant newlines from error messages
commit : 7956d7ac9811a6e97b3aef2ad00272c0b72dc7da
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 2 Jul 2019 23:18:43 +0100
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 2 Jul 2019 23:18:43 +0100
These are no longer needed/allowed with the new logging API.
M src/bin/pg_basebackup/pg_basebackup.c
M src/bin/pg_dump/pg_backup_tar.c
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_rewind/pg_rewind.c
Don't treat complete_from_const as equivalent to complete_from_list.
commit : a4ce93395ef7bced5fae3fbb46d52d0cf6eba2c6
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 Jul 2019 14:04:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 Jul 2019 14:04:42 -0400
Commit 4f3b38fe2 supposed that complete_from_const() is equivalent to
the one-element-list case of complete_from_list(), but that's not
really true at all. complete_from_const() supposes that the completion
is certain enough to justify wiping out whatever the user typed, while
complete_from_list() will only provide completions that match the
word-so-far.
In practice, given the lame parsing technology used by tab-complete.c,
it's fairly hard to believe that we're *ever* certain enough about
a completion to justify auto-correcting user input that doesn't match.
Hence, remove the inappropriate unification of the two cases.
As things now stand, complete_from_const() is used only for the
situation where we have no matches and we need to keep readline
from applying its default complete-with-file-names behavior.
This (mis?) behavior actually exists much further back, but
I'm hesitant to change it in released branches. It's not too
late for v12, though, especially seeing that the aforesaid
commit is new in v12.
Per gripe from Ken Tanzer.
Discussion: https://postgr.es/m/CAD3a31XpXzrZA9TT3BqLSHghdTK+=cXjNCE+oL2Zn4+oWoc=qA@mail.gmail.com
M src/bin/psql/tab-complete.c
Fix tab completion of "SET variable TO|=" to not offer bogus completions.
commit : 4f3648de2a0bcd6eae89cb5cb0d177a672c9e239
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 Jul 2019 13:35:14 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 2 Jul 2019 13:35:14 -0400
Don't think that the context "UPDATE tab SET var =" is a GUC-setting
command.
If we have "SET var =" but the "var" is not a known GUC variable,
don't offer any completions. The most likely explanation is that
we've misparsed the context and it's not really a GUC-setting command.
Per gripe from Ken Tanzer. Back-patch to 9.6. The issue exists
further back, but before 9.6 the code looks very different and it
doesn't actually know whether the "var" name matches anything,
so I desisted from trying to fix it.
Discussion: https://postgr.es/m/CAD3a31XpXzrZA9TT3BqLSHghdTK+=cXjNCE+oL2Zn4+oWoc=qA@mail.gmail.com
M src/bin/psql/tab-complete.c
Revert "Insert temporary debugging output in regression tests."
commit : d4b090f54fe8147157485b2c9b7753731e611354
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Jul 2019 19:46:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Jul 2019 19:46:04 -0400
This reverts commit f03a9ca4366d064d89b7cf7ed75d4e43f2ed0667,
in the v12 branch only. We don't want to ship v12 with that,
since it causes occasional test failures (as a result of statistics
transmission not being entirely reliable).
I'll leave it in HEAD though, in hopes that we'll eventually
capture an instance of the original problematic behavior.
M src/test/regress/expected/select_parallel.out
M src/test/regress/expected/stats.out
M src/test/regress/sql/select_parallel.sql
M src/test/regress/sql/stats.sql
pgindent run prior to branching v12.
commit : 9e1c9f959422192bbe1b842a2a1ffaf76b080196
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Jul 2019 12:37:52 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Jul 2019 12:37:52 -0400
pgperltidy and reformat-dat-files too, though the latter didn't
find anything to change.
M contrib/postgres_fdw/postgres_fdw.h
M src/backend/commands/indexcmds.c
M src/backend/commands/tablecmds.c
M src/backend/commands/tablespace.c
M src/backend/executor/nodeIndexonlyscan.c
M src/backend/executor/nodeModifyTable.c
M src/backend/partitioning/partbounds.c
M src/backend/utils/adt/pg_lsn.c
M src/backend/utils/cache/syscache.c
M src/backend/utils/misc/guc.c
M src/bin/initdb/findtimezone.c
M src/include/catalog/pg_statistic_ext_data.h
M src/tools/msvc/Mkvcbuild.pm
M src/tools/pgindent/README
M src/tools/pgindent/typedefs.list
Doc: remove obsolete description of oid column as being "hidden".
commit : 145b18688c04963efcab8ef3e7e10659bf783eb1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Jul 2019 12:09:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 1 Jul 2019 12:09:06 -0400
Looks like one copy of this text didn't get updated.
Justin Pryzby
Discussion: https://postgr.es/m/20190701155932.GA22866@telsasoft.com
M doc/src/sgml/catalogs.sgml
Revert fix missing call to table_finish_bulk_insert during COPY
commit : f5db56fc4d6e95c582b61c99328ea0702b869fa0
author : David Rowley <drowley@postgresql.org>
date : Tue, 2 Jul 2019 03:44:56 +1200
committer: David Rowley <drowley@postgresql.org>
date : Tue, 2 Jul 2019 03:44:56 +1200
This reverts commits 4de60244e and b2d69806d. Further thought is
required to make this work properly.
M src/backend/commands/copy.c
Remove surplus call to table_finish_bulk_insert
commit : b2d69806d8cc902802a7b56ba37fb7c55e58b0ed
author : David Rowley <drowley@postgresql.org>
date : Tue, 2 Jul 2019 03:07:15 +1200
committer: David Rowley <drowley@postgresql.org>
date : Tue, 2 Jul 2019 03:07:15 +1200
4de60244e added the call to table_finish_bulk_insert to the
CopyMultiInsertBufferCleanup function. We use a CopyMultiInsertBuffer even
for non-partitioned tables, so having the cleanup do that meant we would
call table_finsh_bulk_insert twice when performing COPY FROM with
a non-partitioned table.
Here we can just remove the direct call in CopyFrom and let
CopyMultiInsertBufferCleanup handle the call instead.
M src/backend/commands/copy.c
Fix missing call to table_finish_bulk_insert during COPY
commit : 4de60244e2fcdeb100afc7f8bf5c28b32923a637
author : David Rowley <drowley@postgresql.org>
date : Tue, 2 Jul 2019 01:23:26 +1200
committer: David Rowley <drowley@postgresql.org>
date : Tue, 2 Jul 2019 01:23:26 +1200
86b85044e abstracted calls to heap functions in COPY FROM to support a
generic table AM. However, when performing a copy into a partitioned
table, this commit neglected to call table_finish_bulk_insert for each
partition. Before 86b85044e, when we always called the heap functions,
there was no need to call heapam_finish_bulk_insert for partitions since
it only did any work when performing a copy without WAL. For partitioned
tables, this was unsupported anyway, so there was no issue. With pluggable
storage, we can't make any assumptions about what the table AM might want
to do in its equivalent function, so we'd better ensure we always call
table_finish_bulk_insert each partition that's received a row.
For now, we make the table_finish_bulk_insert call whenever we evict a
CopyMultiInsertBuffer out of the CopyMultiInsertInfo. This does mean
that it's possible that we call table_finish_bulk_insert multiple times
per partition, which is not a problem other than being an inefficiency.
Improving this requires a more invasive patch, so let's leave that for
another day.
In passing, move the table_finish_bulk_insert for the target of the COPY
command so that it's only called when we're actually performing bulk
inserts. We don't need to call this when inserting 1 row at a time.
Reported-by: Robert Haas
Discussion: https://postgr.es/m/CA+TgmoYK=6BpxiJ0tN-p9wtH0BTAfbdxzHhwou0mdud4+BkYuQ@mail.gmail.com
M src/backend/commands/copy.c
Convert some stragglers to new frontend logging API
commit : 95bbe5d82e428db342fa3ec60b95f1b9873741e5
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 1 Jul 2019 13:34:31 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 1 Jul 2019 13:34:31 +0200
M src/bin/initdb/initdb.c
Add missing serial commas
commit : 1b29e990e352885642149262859b83c19d362405
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 1 Jul 2019 13:07:14 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 1 Jul 2019 13:07:14 +0200
M src/backend/catalog/pg_proc.c
M src/bin/pg_checksums/pg_checksums.c
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dumpall.c
M src/bin/pg_dump/t/001_basic.pl
Fix many typos and inconsistencies
commit : c74d49d41c9e0fabeb1179dcabfb3137833ed831
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 1 Jul 2019 10:00:23 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 1 Jul 2019 10:00:23 +0900
Author: Alexander Lakhin
Discussion: https://postgr.es/m/af27d1b3-a128-9d62-46e0-88f424397f44@gmail.com
M contrib/bloom/blutils.c
M contrib/intarray/_int_selfuncs.c
M contrib/pg_trgm/trgm_regexp.c
M contrib/pgcrypto/crypt-des.c
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
M doc/src/sgml/diskusage.sgml
M src/backend/access/brin/brin_tuple.c
M src/backend/access/nbtree/nbtree.c
M src/backend/access/nbtree/nbtxlog.c
M src/backend/catalog/heap.c
M src/backend/executor/execExpr.c
M src/backend/libpq/be-fsstubs.c
M src/backend/nodes/tidbitmap.c
M src/backend/optimizer/path/equivclass.c
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/util/clauses.c
M src/backend/parser/analyze.c
M src/backend/parser/gram.y
M src/backend/parser/parse_target.c
M src/backend/postmaster/bgworker.c
M src/backend/replication/logical/logical.c
M src/backend/replication/slot.c
M src/backend/rewrite/rewriteHandler.c
M src/backend/storage/buffer/freelist.c
M src/backend/storage/buffer/localbuf.c
M src/backend/storage/ipc/barrier.c
M src/backend/utils/Gen_dummy_probes.pl
M src/backend/utils/adt/arrayfuncs.c
M src/backend/utils/adt/date.c
M src/backend/utils/adt/datetime.c
M src/backend/utils/adt/oracle_compat.c
M src/backend/utils/cache/plancache.c
M src/backend/utils/mmgr/dsa.c
M src/backend/utils/mmgr/freepage.c
M src/include/access/attnum.h
M src/include/access/hash.h
M src/include/commands/event_trigger.h
M src/include/commands/extension.h
M src/include/executor/nodeCustom.h
M src/include/funcapi.h
M src/include/nodes/primnodes.h
M src/include/optimizer/cost.h
M src/include/optimizer/pathnode.h
M src/include/storage/fd.h
M src/include/storage/proc.h
M src/include/tcop/tcopprot.h
M src/include/utils/inval.h
M src/include/utils/sortsupport.h
M src/interfaces/libpq/fe-auth.c
Don't read fields of a misaligned ExpandedObjectHeader or AnyArrayType.
commit : 459c3cdb4ad8323bfe6bcae0186a3831e0c89c94
author : Noah Misch <noah@leadboat.com>
date : Sun, 30 Jun 2019 17:34:17 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sun, 30 Jun 2019 17:34:17 -0700
UBSan complains about this. Instead, cast to a suitable type requiring
only 4-byte alignment. DatumGetAnyArrayP() already assumes one can cast
between AnyArrayType and ArrayType, so this doesn't introduce a new
assumption. Back-patch to 9.5, where AnyArrayType was introduced.
Reviewed by Tom Lane.
Discussion: https://postgr.es/m/20190629210334.GA1244217@rfd.leadboat.com
M src/backend/utils/adt/arrayfuncs.c
M src/include/utils/array.h
M src/include/utils/arrayaccess.h
M src/include/utils/expandeddatum.h
Repair logic for reordering grouping sets optimization.
commit : da53be23d1c5e529675e958eaee54cfed4e4dbac
author : Andrew Gierth <rhodiumtoad@postgresql.org>
date : Sun, 30 Jun 2019 23:49:13 +0100
committer: Andrew Gierth <rhodiumtoad@postgresql.org>
date : Sun, 30 Jun 2019 23:49:13 +0100
The logic in reorder_grouping_sets to order grouping set elements to
match a pre-specified sort ordering was defective, resulting in
unnecessary sort nodes (though the query output would still be
correct). Repair, simplifying the code a little, and add a test.
Per report from Richard Guo, though I didn't use their patch. Original
bug seems to have been my fault.
Backpatch back to 9.5 where grouping sets were introduced.
Discussion: https://postgr.es/m/CAN_9JTzyjGcUjiBHxLsgqfk7PkdLGXiM=pwM+=ph2LsWw0WO1A@mail.gmail.com
M src/backend/optimizer/plan/planner.c
M src/test/regress/expected/groupingsets.out
M src/test/regress/sql/groupingsets.sql
Exclude new src/test/modules/unsafe_tests directory from MSVC build.
commit : c000a47ad1fdd4fb92c7068279d97e0c3db4f8eb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 30 Jun 2019 14:05:24 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 30 Jun 2019 14:05:24 -0400
There's nothing to build here, and that was confusing AddContrib().
Per buildfarm.
M src/tools/msvc/Mkvcbuild.pm
Blind attempt to fix SSPI-auth case in 010_dump_connstr.pl.
commit : 681cca86f5071379c4a8599ef9387b666b7e6879
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 30 Jun 2019 13:34:45 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 30 Jun 2019 13:34:45 -0400
Up to now, pg_regress --config-auth had a hard-wired assumption
that the target cluster uses the default bootstrap superuser name.
pg_dump's 010_dump_connstr.pl TAP test uses non-default superuser
names, and was klugily getting around the restriction by listing
the desired superuser name as a role to "create". This is pretty
confusing (or at least, it confused me). Let's make it clearer by
allowing --config-auth mode to be told the bootstrap superuser name.
Repurpose the existing --user switch for that, since it has no
other function in --config-auth mode.
Per buildfarm. I don't have an environment at hand in which I can
test this fix, but the buildfarm should soon show if it works.
Discussion: https://postgr.es/m/3142.1561840611@sss.pgh.pa.us
M src/bin/pg_dump/t/010_dump_connstr.pl
M src/test/regress/pg_regress.c
Move rolenames test out of the core regression tests.
commit : c91504b958e1647f87ffb7168e61db75ca09b928
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 30 Jun 2019 12:51:08 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 30 Jun 2019 12:51:08 -0400
This test script is unsafe to run in "make installcheck" mode for
(at least) two reasons: it creates and destroys some role names
that don't follow the "regress_xxx" naming convention, and it
sets and then resets the application_name GUC attached to every
existing role. While we've not had complaints, these surely are
not good things to do within a production installation, and
regress.sgml pretty clearly implies that we won't do them.
Rather than lose test coverage altogether, let's just move this
script somewhere where it will get run by "make check" but not
"make installcheck". src/test/modules/ already has that property.
Since it seems likely that we'll want other regression tests in
future that also exceed the constraints of "make installcheck",
create a generically-named src/test/modules/unsafe_tests/
directory to hold them.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
M src/test/modules/Makefile
A src/test/modules/unsafe_tests/.gitignore
A src/test/modules/unsafe_tests/Makefile
A src/test/modules/unsafe_tests/README
R100 src/test/regress/expected/rolenames.out src/test/modules/unsafe_tests/expected/rolenames.out
R100 src/test/regress/sql/rolenames.sql src/test/modules/unsafe_tests/sql/rolenames.sql
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
Fix breakage introduced in pg_lsn_in()
commit : 2e810508f6b0d89621094445620a1bea3ceff3f1
author : Peter Eisentraut <peter@eisentraut.org>
date : Sun, 30 Jun 2019 13:25:33 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sun, 30 Jun 2019 13:25:33 +0200
Using PG_RETURN_LSN() from non-fmgr pg_lsn_in_internal() happened to
work on some platforms, but should just be a plain "return".
M src/backend/utils/adt/pg_lsn.c
Don't call data type input functions in GUC check hooks
commit : 21f428ebde39339487c271a830fed135d6032d73
author : Peter Eisentraut <peter@eisentraut.org>
date : Sun, 30 Jun 2019 10:15:25 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sun, 30 Jun 2019 10:15:25 +0200
Instead of calling pg_lsn_in() in check_recovery_target_lsn and
timestamptz_in() in check_recovery_target_time, reorganize the
respective code so that we don't raise any errors in the check hooks.
The previous code tried to use PG_TRY/PG_CATCH to handle errors in a
way that is not safe, so now the code contains no ereport() calls and
can operate safely within the GUC error handling system.
Moreover, since the interpretation of the recovery_target_time string
may depend on the time zone, we cannot do the final processing of that
string until all the GUC processing is done. Instead,
check_recovery_target_time() now does some parsing for syntax
checking, but the actual conversion to a timestamptz value is done
later in the recovery code that uses it.
Reported-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://www.postgresql.org/message-id/flat/20190611061115.njjwkagvxp4qujhp%40alap3.anarazel.de
M src/backend/access/transam/xlog.c
M src/backend/utils/adt/pg_lsn.c
M src/backend/utils/misc/guc.c
M src/include/access/xlog.h
M src/include/utils/pg_lsn.h
Remove explicit error handling for obsolete date/time values
commit : 666cbae16da46b833f57ef8b12ff0bf215684d9c
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 12 Jun 2019 11:29:53 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 12 Jun 2019 11:29:53 +0200
The date/time values 'current', 'invalid', and 'undefined' were
removed a long time ago, but the code still contains explicit error
handling for the transition. To simplify the code and avoid having to
handle these values everywhere, just remove the recognition of these
tokens altogether now.
Reviewed-by: Michael Paquier <michael@paquier.xyz>
M src/backend/utils/adt/date.c
M src/backend/utils/adt/datetime.c
M src/backend/utils/adt/timestamp.c
M src/include/utils/datetime.h
M src/interfaces/ecpg/pgtypeslib/dt.h
M src/interfaces/ecpg/pgtypeslib/dt_common.c
M src/interfaces/ecpg/pgtypeslib/timestamp.c
M src/test/regress/expected/date.out
M src/test/regress/expected/timestamp.out
M src/test/regress/expected/timestamptz.out
M src/test/regress/sql/date.sql
M src/test/regress/sql/timestamp.sql
M src/test/regress/sql/timestamptz.sql
Add an enforcement mechanism for global object names in regression tests.
commit : 54100f5c6052404f68de9ce7310ceb61f1c291f8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 29 Jun 2019 11:34:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 29 Jun 2019 11:34:00 -0400
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have
on an existing installation.
This commit adds a simple enforcement mechanism for that rule: if the code
is compiled with ENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS defined, it
will emit a warning (not an error) whenever a database, role, tablespace,
subscription, or replication origin name is created that doesn't obey the
rule. Running one or more buildfarm members with that symbol defined
should be enough to catch new violations, at least in the regular
regression tests. Most TAP tests wouldn't notice such warnings, but
that's actually fine because TAP tests don't execute against an existing
server anyway.
Since it's already the case that running src/test/modules/ tests in
installcheck mode is deprecated, we can use that as a home for tests
that seem unsafe to run against an existing server, such as tests that
might have side-effects on existing roles. Document that (though this
commit doesn't in itself make it any less safe than before).
Update regress.sgml to define these restrictions more clearly, and
to clean up assorted lack-of-up-to-date-ness in its descriptions of
the available regression tests.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
M doc/src/sgml/regress.sgml
M src/backend/commands/alter.c
M src/backend/commands/dbcommands.c
M src/backend/commands/subscriptioncmds.c
M src/backend/commands/tablespace.c
M src/backend/commands/user.c
M src/backend/replication/logical/origin.c
M src/test/modules/README
Fix regression tests to use only global names beginning with "regress_".
commit : ca129e58c01f29ef24a734313ff315933b3d5b67
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 29 Jun 2019 11:09:03 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 29 Jun 2019 11:09:03 -0400
In commit 18555b132 we tentatively established a rule that regression
tests should use names containing "regression" for databases, and names
starting with "regress_" for all other globally-visible object names, so
as to circumscribe the side-effects that "make installcheck" could have on
an existing installation. However, no enforcement mechanism was created,
so it's unsurprising that some new violations have crept in since then.
In fact, a whole new *category* of violations has crept in, to wit we now
also have globally-visible subscription and replication origin names, and
"make installcheck" could very easily clobber user-created objects of
those types. So it's past time to do something about this.
This commit sanitizes the tests enough that they will pass (i.e. not
generate any visible warnings) with the enforcement mechanism I'll add
in the next commit. There are some TAP tests that still trigger the
warnings, but the warnings do not cause test failure. Since these tests
do not actually run against a pre-existing installation, there's no need
to worry whether they could conflict with user-created objects.
The problem with rolenames.sql testing special role names like "user"
is still there, and is dealt with only very cosmetically in this patch
(by hiding the warnings :-(). What we actually need to do to be safe is
to take that test script out of "make installcheck" altogether, but that
seems like material for a separate patch.
Discussion: https://postgr.es/m/16638.1468620817@sss.pgh.pa.us
M contrib/test_decoding/expected/replorigin.out
M contrib/test_decoding/expected/rewrite.out
M contrib/test_decoding/sql/replorigin.sql
M contrib/test_decoding/sql/rewrite.sql
M src/bin/pg_dump/t/010_dump_connstr.pl
M src/bin/pg_upgrade/test.sh
M src/test/regress/expected/object_address.out
M src/test/regress/expected/rolenames.out
M src/test/regress/expected/subscription.out
M src/test/regress/sql/object_address.sql
M src/test/regress/sql/rolenames.sql
M src/test/regress/sql/subscription.sql
Disallow user-created replication origins named "pg_xxx".
commit : a1e61badf97bc446053145ba40de6db835678ce3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 29 Jun 2019 10:30:08 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 29 Jun 2019 10:30:08 -0400
Since we generate such names internally, it seems like a good idea
to have a policy of disallowing them for user use, as we do for many
other object types. Otherwise attempts to use them will randomly
fail due to collisions with internally-generated names.
Discussion: https://postgr.es/m/3606.1561747369@sss.pgh.pa.us
M src/backend/replication/logical/origin.c
Remove unnecessary header from be-secure-gssapi.c
commit : c0faa727507ed34db0d02769d21bbaaf9605e2e4
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 29 Jun 2019 11:14:21 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 29 Jun 2019 11:14:21 +0900
libpq/libpq-be.h is included by libpq/libpq.h so there is no need to
explicitly include it separately.
Author: Daniel Gustafsson
Reviewed-by: Julien Rouhaud
Discussion: https://postgr.es/m/A4852E46-9ED1-4861-A23B-22A83E34A084@yesql.se
M src/backend/libpq/be-secure-gssapi.c
Fix for dropped columns in a partitioned table's default partition
commit : 23cccb17fe0bbb5df86780da5c346cc060c21421
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 28 Jun 2019 14:51:08 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 28 Jun 2019 14:51:08 -0400
We forgot to map column numbers to/from the default partition for
various operations, leading to valid cases failing with spurious
errors, such as
ERROR: attribute N of type some_partition has been dropped
It was also possible that the search for conflicting rows in the default
partition when attaching another partition would fail to detect some.
Secondarily, it was also possible that such a search should be skipped
(because the constraint was implied) but wasn't.
Fix all this by mapping column numbers when necessary.
Reported by: Daniel Wilches
Author: Amit Langote
Discussion: https://postgr.es/m/15873-8c61945d6b3ef87c@postgresql.org
M src/backend/commands/tablecmds.c
M src/backend/partitioning/partbounds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/expected/create_table.out
M src/test/regress/sql/alter_table.sql
M src/test/regress/sql/create_table.sql
Fix misleading comment in nodeIndexonlyscan.c.
commit : 74b7cc8c02137f059703972aa14445b1e073f005
author : Thomas Munro <tmunro@postgresql.org>
date : Fri, 28 Jun 2019 11:11:26 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Fri, 28 Jun 2019 11:11:26 +1200
The stated reason for acquiring predicate locks on heap pages hasn't
existed since commit c01262a8, so fix the comment. Perhaps in a later
release we'll also be able to change the code to use tuple locks.
Back-patch all the way.
Reviewed-by: Ashwin Agrawal
Discussion: https://postgr.es/m/CAEepm%3D2GK3FVdnt5V3d%2Bh9njWipCv_fNL%3DwjxyUhzsF%3D0PcbNg%40mail.gmail.com
M src/backend/executor/nodeIndexonlyscan.c
Update reference to sampling algorithm in analyze.c
commit : 69fd82fedd746b82427097883daf2921dd77584e
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Thu, 27 Jun 2019 17:41:29 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Thu, 27 Jun 2019 17:41:29 +0200
Commit 83e176ec1 moved row sampling functions from analyze.c to
utils/misc/sampling.c, but failed to update comment referring to
the sampling algorithm from Jeff Vitter's paper. Correct the
comment by pointing to utils/misc/sampling.c.
Author: Etsuro Fujita
Discussion: https://postgr.es/m/CAPmGK154gp%2BQd%3DcorQOv%2BPmbyVyZBjp_%2Bhb766UJeD1e_ie6XQ%40mail.gmail.com
M src/backend/commands/analyze.c
Fix use-after-free introduced in 55ed3defc966
commit : 050098b14e33a5d3dfabf172ebbddd20c6bb4665
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 27 Jun 2019 11:57:10 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 27 Jun 2019 11:57:10 -0400
Evidenced by failure under RELCACHE_FORCE_RELEASE (buildfarm member
prion).
Author: Amit Langote
Discussion: https://postgr.es/m/CA+HiwqGV=k_Eh4jBiQw66ivvdG+EUkrEYeHTYL1SvDj_YOYV0g@mail.gmail.com
M src/backend/commands/indexcmds.c
Update comment
commit : f2f0082ef5969b57d0b52d0c2e891872ed1b0a51
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 27 Jun 2019 15:57:14 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 27 Jun 2019 15:57:14 +0200
Function was renamed/replaced in
c2fe139c201c48f1133e9fbea2dd99b8efe2fadd but the header comment was
not updated.
M src/backend/access/index/indexam.c
Remove remaining traces of Rand_OpenSSL() from the tree
commit : 322c5bfdc3d76f6463768ecd8fced30c881b8be5
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 27 Jun 2019 08:25:26 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 27 Jun 2019 08:25:26 +0900
fe0a0b5 has removed the last use of this routine from pgcrypto, leading
to a useless symbol definition and an extra configure check.
Author: Michael Paquier
Reviewed-by: Daniel Gustafsson, Tom Lane
Discussion: https://postgr.es/m/20190626142544.GN1714@paquier.xyz
M configure
M configure.in
M src/include/pg_config.h.in
Fix partitioned index creation with foreign partitions
commit : 55ed3defc966cf718fe1e8c0efe964580bb23351
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 26 Jun 2019 18:38:51 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 26 Jun 2019 18:38:51 -0400
When a partitioned tables contains foreign tables as partitions, it is
not possible to implement unique or primary key indexes -- but when
regular indexes are created, there is no reason to do anything other
than ignoring such partitions. We were raising errors upon encountering
the foreign partitions, which is unfriendly and doesn't protect against
any actual problems.
Relax this restriction so that index creation is allowed on partitioned
tables containing foreign partitions, becoming a no-op on them. (We may
later want to redefine this so that the FDW is told to create the
indexes on the foreign side.) This applies to CREATE INDEX, as well as
ALTER TABLE / ATTACH PARTITION and CREATE TABLE / PARTITION OF.
Backpatch to 11, where indexes on partitioned tables were introduced.
Discussion: https://postgr.es/m/15724-d5a58fa9472eef4f@postgresql.org
Author: Álvaro Herrera
Reviewed-by: Amit Langote
M doc/src/sgml/ref/alter_table.sgml
M doc/src/sgml/ref/create_foreign_table.sgml
M src/backend/commands/indexcmds.c
M src/backend/commands/tablecmds.c
M src/backend/tcop/utility.c
M src/test/regress/expected/foreign_data.out
M src/test/regress/sql/foreign_data.sql
Follow the rule that regression-test-created roles are named "regress_xxx".
commit : 65e6d42140c8d9918638b9f73528288ab980af82
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 25 Jun 2019 23:06:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 25 Jun 2019 23:06:17 -0400
contrib/amcheck didn't get the memo either.
M contrib/amcheck/expected/check_btree.out
M contrib/amcheck/sql/check_btree.sql
Follow the rule that regression-test-created roles are named "regress_xxx".
commit : c360477d2e2f65fdea64aa8bc94a6286d0883f7a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 25 Jun 2019 22:53:42 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 25 Jun 2019 22:53:42 -0400
Commit 1c5d9270e had not gotten the word about this. (For previous
context, see 18555b132.)
M src/test/regress/expected/psql.out
M src/test/regress/sql/psql.sql
Add support for OpenSSL 1.1.0 and newer versions in MSVC scripts
commit : d993e0fb82ffaa15be72c1ac10403bfa06708069
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 26 Jun 2019 10:44:46 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 26 Jun 2019 10:44:46 +0900
Up to now, the MSVC build scripts are able to support only one fixed
version of OpenSSL, and they lacked logic to detect the version of
OpenSSL a given compilation of Postgres is linking to (currently 1.0.2,
the latest LTS of upstream which will be EOL'd at the end of 2019).
This commit adds more logic to detect the version of OpenSSL used by a
build and makes use of it to add support for compilation with OpenSSL
1.1.0 which requires a new set of compilation flags to work properly.
The supported OpenSSL installers have changed their library layer with
various library renames with the upgrade to 1.1.0, making the logic a
bit more complicated. The scripts are now able to adapt to the new
world order.
Reported-by: Sergey Pashkov
Author: Juan José Santamaría Flecha, Michael Paquier
Reviewed-by: Álvaro Herrera
Discussion: https://postgr.es/m/15789-8fc75dea3c5a17c8@postgresql.org
M src/tools/msvc/Solution.pm
Add toast-level reloption for vacuum_index_cleanup
commit : ce59b75d449d9152667ce3e9eab33ef2872bfd98
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 25 Jun 2019 09:09:27 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 25 Jun 2019 09:09:27 +0900
a96c41f has introduced the option for heap, but it still lacked the
variant to control the behavior for toast relations.
While on it, refactor the tests so as they stress more scenarios with
the various values that vacuum_index_cleanup can use. It would be
useful to couple those tests with pageinspect to check that pages are
actually cleaned up, but this is left for later.
Author: Masahiko Sawada, Michael Paquier
Reviewed-by: Peter Geoghegan
Discussion: https://postgr.es/m/CAD21AoCqs8iN04RX=i1KtLSaX5RrTEM04b7NHYps4+rqtpWNEg@mail.gmail.com
M doc/src/sgml/ref/create_table.sgml
M src/backend/access/common/reloptions.c
M src/bin/psql/tab-complete.c
M src/test/regress/expected/vacuum.out
M src/test/regress/sql/vacuum.sql
Don't unset MAKEFLAGS in non-GNU Makefile.
commit : 0089c3059cb6b3dd20cf072f26d1a7a33412df39
author : Thomas Munro <tmunro@postgresql.org>
date : Tue, 25 Jun 2019 09:29:53 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Tue, 25 Jun 2019 09:29:53 +1200
It's useful to be able to pass down options like -s and -j.
Back-patch to 9.5, like commit a76200de.
Discussion: https://postgr.es/m/CA%2BhUKG%2Be1M8-BbL%3DPqhTp6oO6XPO6%2Bs9WGQMLfbuZ%3DG9CtzyXg%40mail.gmail.com
M Makefile
Remove misleading comment from pathnodes.h.
commit : a2dec374807565f6337915fb236bb3ae37af0644
author : Thomas Munro <tmunro@postgresql.org>
date : Tue, 25 Jun 2019 09:17:04 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Tue, 25 Jun 2019 09:17:04 +1200
As of commit e5253fdc, it is no longer true that the leader always
executes the subplan of a Gather Merge node. Remove comment to that
effect.
Back-patch to 11.
Discussion: https://postgr.es/m/CA%2BhUKGJEaZJYezXAOutuiWT%2BfxCA44%2BoKtVPAND2ubLiigR%3D-w%40mail.gmail.com
M src/include/nodes/pathnodes.h
Purely-cosmetic adjustments in tablecmds.c.
commit : ccfcc8fdbd9bdbfd18fda5d7c698af8d175f5319
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 24 Jun 2019 17:19:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 24 Jun 2019 17:19:32 -0400
Move ATExecAlterColumnGenericOptions away from where it was unthinkingly
dropped, in the middle of a lot of ALTER COLUMN TYPE code. I don't have
any high principles about where to put it instead, so let's just put it
after ALTER COLUMN TYPE and before ALTER OWNER, matching existing
decisions about how to order related code stanzas.
Also add the minimal function header comment that the original author
was too cool to bother with.
Along the way, upgrade header comments for nearby ALTER COLUMN TYPE
functions.
Discussion: https://postgr.es/m/14787.1561403130@sss.pgh.pa.us
M src/backend/commands/tablecmds.c
Update unicode_norm_table.h to Unicode 12.1.0
commit : 82be666ee36842af2a1b81e570bd5578f264de65
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 19 Jun 2019 22:15:43 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 19 Jun 2019 22:15:43 +0200
M src/include/common/unicode_norm_table.h
Make script output more pgindent compatible
commit : 2cadefbb97ff8e5566476780dc200db06af6ba09
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 19 Jun 2019 22:09:50 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 19 Jun 2019 22:09:50 +0200
M src/common/unicode/generate-unicode_norm_table.pl
Correct script name in README file
commit : eb8d05bfeca416a970cc33af5915ec7b4f4a2f69
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 19 Jun 2019 22:09:29 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 19 Jun 2019 22:09:29 +0200
M src/common/unicode/README
Further fix ALTER COLUMN TYPE's handling of indexes and index constraints.
commit : f946a409143d01951411382fbc3c91c7eb640094
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 24 Jun 2019 16:43:05 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 24 Jun 2019 16:43:05 -0400
This patch reverts all the code changes of commit e76de8861, which turns
out to have been seriously misguided. We can't wait till later to compute
the definition string for an index; we must capture that before applying
the data type change for any column it depends on, else ruleutils.c will
deliverr wrong/misleading results. (This fine point was documented
nowhere, of course.)
I'd also managed to forget that ATExecAlterColumnType executes once per
ALTER COLUMN TYPE clause, not once per statement; which resulted in the
code being basically completely broken for any case in which multiple ALTER
COLUMN TYPE clauses are applied to a table having non-constraint indexes
that must be rebuilt. Through very bad luck, none of the existing test
cases nor the ones added by e76de8861 caught that, but of course it was
soon found in the field.
The previous patch also had an implicit assumption that if a constraint's
index had a dependency on a table column, so would the constraint --- but
that isn't actually true, so it didn't fix such cases.
Instead of trying to delete unneeded index dependencies later, do the
is-there-a-constraint lookup immediately on seeing an index dependency,
and switch to remembering the constraint if so. In the unusual case of
multiple column dependencies for a constraint index, this will result in
duplicate constraint lookups, but that's not that horrible compared to all
the other work that happens here. Besides, such cases did not work at all
before, so it's hard to argue that they're performance-critical for anyone.
Per bug #15865 from Keith Fiske. As before, back-patch to all supported
branches.
Discussion: https://postgr.es/m/15865-17940eacc8f8b081@postgresql.org
M src/backend/commands/tablecmds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Correct obsolete amcheck comments.
commit : b00326df7ad4ab7d21aad3b6fe6558ea6b61897d
author : Peter Geoghegan <pg@bowt.ie>
date : Mon, 24 Jun 2019 10:31:58 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Mon, 24 Jun 2019 10:31:58 -0700
Oversight in commit dd299df8.
M contrib/amcheck/verify_nbtree.c
Drop test user when done with it.
commit : f31111bbe81db0e84fb486c6423a234c47091b30
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 24 Jun 2019 12:36:51 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 24 Jun 2019 12:36:51 -0400
Commit d7f8d26d9 added a test case that created a user, but forgot
to drop it again. This is no good; for one thing, it causes repeated
"make installcheck" runs to fail.
M src/test/regress/expected/stats_ext.out
M src/test/regress/sql/stats_ext.sql
Upgrade internal error message to external
commit : 12e037e2090b1a6446376814ea0419463b02c254
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 24 Jun 2019 10:39:12 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 24 Jun 2019 10:39:12 +0200
As part of REINDEX CONCURRENTLY, this formerly internal-only error
message becomes potentially user-visible (see regression tests), so
change from errmsg_internal() to errmsg(), and update comment.
M src/backend/catalog/index.c
Don't call PG_RETURN_BOOL() in a function not returning Datum.
commit : 9a81c9fa3f6a2f57b9db2a1ce5584c85fc1d977e
author : Noah Misch <noah@leadboat.com>
date : Sun, 23 Jun 2019 12:02:19 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sun, 23 Jun 2019 12:02:19 -0700
This code is new in v12, and the defect probably was not user-visible.
M src/backend/utils/adt/timestamp.c
Add security checks to the multivariate MCV estimation code.
commit : d7f8d26d9f4c0a574250ec53a03b3dc08d13796c
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sun, 23 Jun 2019 18:50:08 +0100
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Sun, 23 Jun 2019 18:50:08 +0100
The multivariate MCV estimation code may run user-defined operators on
the values in the MCV list, which means that those operators may
potentially leak the values from the MCV list. Guard against leaking
data to unprivileged users by checking that the user has SELECT
privileges on the table or all of the columns referred to by the
statistics.
Additionally, if there are any securityQuals on the RTE (either due to
RLS policies on the table, or accessing the table via a security
barrier view), not all rows may be visible to the current user, even
if they have table or column privileges. Thus we further insist that
the operator be leakproof in this case.
Dean Rasheed, reviewed by Tomas Vondra.
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui=Vdx4N==VV5XOK5dsXfnGgVOz_JhAicB=ZA@mail.gmail.com
M src/backend/statistics/extended_stats.c
M src/test/regress/expected/stats_ext.out
M src/test/regress/sql/stats_ext.sql
Remove unnecessary comment.
commit : 89ff7c08eee355195eba6f544d28584e61200665
author : Thomas Munro <tmunro@postgresql.org>
date : Sun, 23 Jun 2019 22:19:59 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Sun, 23 Jun 2019 22:19:59 +1200
Author: Vik Fearing
Discussion: https://postgr.es/m/150d3e9f-c7ec-3fb3-4fdb-def47c4144af%402ndquadrant.com
M src/backend/access/nbtree/nbtpage.c
Fix spinlock assembly code for MIPS so it works on MIPS r6.
commit : 1323bfce55109dd54ee164828aab7983d3020a25
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 22 Jun 2019 20:31:50 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 22 Jun 2019 20:31:50 -0400
Original MIPS-I processors didn't have the LL/SC instructions (nor any
other userland synchronization primitive). If the build toolchain
targets that ISA variant by default, as an astonishingly large fraction
of MIPS platforms still do, the assembler won't take LL/SC without
coercion in the form of a ".set mips2" instruction. But we issued that
unconditionally, making it an ISA downgrade for chips later than MIPS2.
That breaks things for the latest MIPS r6 ISA, which encodes these
instructions differently. Adjust the code so we don't change ISA level
if it's >= 2.
Note that this patch doesn't change what happens on an actual MIPS-I
processor: either the kernel will emulate these instructions
transparently, or you'll get a SIGILL failure. That tradeoff seemed
fine in 2002 when this code was added (cf 3cbe6b247), and it's even
more so today when MIPS-I is basically extinct. But let's add a
comment about that.
YunQiang Su (with cosmetic adjustments by me). Back-patch to all
supported branches.
Discussion: https://postgr.es/m/15844-8f62fe7e163939b3@postgresql.org
M src/include/storage/s_lock.h
Consolidate methods for translating a Perl path to a Windows path.
commit : 660a2b19038b2f6b9f6bcb2c3297a47d5e3557a8
author : Noah Misch <noah@leadboat.com>
date : Fri, 21 Jun 2019 20:34:23 -0700
committer: Noah Misch <noah@leadboat.com>
date : Fri, 21 Jun 2019 20:34:23 -0700
This fixes some TAP suites when using msys Perl and a builddir located
in an msys mount point other than "/". For example, builddir=/c/pg
exhibited the problem, since /c/pg falls in mount point "/c".
Back-patch to 9.6, where tests first started to perform such
translations. In back branches, offer both new and old APIs.
Reviewed by Andrew Dunstan.
Discussion: https://postgr.es/m/20190610045838.GA238501@rfd.leadboat.com
M src/bin/pg_checksums/t/002_actions.pl
M src/test/perl/PostgresNode.pm
M src/test/perl/TestLib.pm
M src/test/recovery/t/014_unlogged_reinit.pl
M src/test/recovery/t/017_shm.pl
Remove obsolete comments about sempahores from proc.c.
commit : 25b93a2967a4ebfb90168ca087026cc697fc4b77
author : Thomas Munro <tmunro@postgresql.org>
date : Fri, 21 Jun 2019 10:57:07 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Fri, 21 Jun 2019 10:57:07 +1200
Commit 6753333f switched from a semaphore-based wait to a latch-based
wait for ProcSleep()/ProcWakeup(), but left behind some stray references
to semaphores.
Back-patch to 9.5.
Reviewed-by: Daniel Gustafsson, Michael Paquier
Discussion: https://postgr.es/m/CA+hUKGLs5H6zhmgTijZ1OaJvC1sG0=AFXc1aHuce32tKiQrdEA@mail.gmail.com
M src/backend/storage/lmgr/proc.c
Rework some error strings for REINDEX CONCURRENTLY with system catalogs
commit : 20e1cc898da6f82b5680973c107e8a96d46caf01
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 20 Jun 2019 13:28:12 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 20 Jun 2019 13:28:12 +0900
This makes the whole user experience more consistent when bumping into
failures, and more in line with the rewording done via 508300e.
Author: Michael Paquier
Reviewed-by: Álvaro Herrera
Discussion: https://postgr.es/m/20190514153252.GA22168@alvherre.pgsql
M src/backend/commands/indexcmds.c
M src/test/regress/expected/create_index.out
Fix description of pg_class.relam for table access methods
commit : 252f9a2580b013fe45ba28bb6d7a4994abc93bb5
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 20 Jun 2019 13:04:56 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 20 Jun 2019 13:04:56 +0900
Author: Ian Barwick
Discussion: https://postgr.es/m/087a6961-1aaf-e36c-b712-bd5a644da20a@2ndquadrant.com
M doc/src/sgml/catalogs.sgml
pg_upgrade: Improve error messages
commit : cd917ffb9a43e9e4699c2a89d495ee02a8701034
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 19 Jun 2019 21:49:03 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 19 Jun 2019 21:49:03 +0200
Make wording more accurate and add strerror() information.
Discussion: https://www.postgresql.org/message-id/24c8bd05-aed1-6301-919d-8acbabdb8c24@2ndquadrant.com
M src/bin/pg_upgrade/exec.c
M src/bin/pg_upgrade/option.c
pg_upgrade: Improve invalid option handling
commit : aba78ab4a9509e7ed92acefd707a99425568f49f
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 19 Jun 2019 21:43:31 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 19 Jun 2019 21:43:31 +0200
Currently, calling pg_upgrade with an invalid command-line option
aborts pg_upgrade but leaves a pg_upgrade_internal.log file lying
around. Reorder things a bit so that that file is not created until
all the options have been parsed.
Discussion: https://www.postgresql.org/message-id/24c8bd05-aed1-6301-919d-8acbabdb8c24@2ndquadrant.com
M src/bin/pg_upgrade/option.c
Fix description for $varname jsonpath variable
commit : dfd79e2d0e8f399785ca2f7c659b45fd620cba17
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Wed, 19 Jun 2019 22:41:12 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Wed, 19 Jun 2019 22:41:12 +0300
The description is ended part way and PASSING clause is not implemented yet.
But the variables might be passed as parameters to several jsonpath functions.
So, complete the description based on the current implementation, leaving
description of PASSING clause in TODO.
Discussion: https://postgr.es/m/CAKPRHz%2BxOuQSSvkuB1mCQjedd%2BB2B1Vnkrq0E-pLmoXyTO%2Bz9Q%40mail.gmail.com
Author: Kyotaro Horiguchi, Alexander Korotkov
M doc/src/sgml/json.sgml
Improve documentation for jsonpath like_regex predicate
commit : 1ff8dc9f19ddf00e3ad69d7141f78341769cd8a3
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Wed, 19 Jun 2019 22:41:05 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Wed, 19 Jun 2019 22:41:05 +0300
Reference posix regex documentation section and list supported flags.
Discussion: https://postgr.es/m/CAKPRHz%2BxOuQSSvkuB1mCQjedd%2BB2B1Vnkrq0E-pLmoXyTO%2Bz9Q%40mail.gmail.com
Author: Kyotaro Horiguchi, Alexander Korotkov
M doc/src/sgml/func.sgml
Support 'q' flag in jsonpath 'like_regex' predicate
commit : 261a5c1928566f938cbda0f62dc16f6a2d1e871d
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Wed, 19 Jun 2019 22:40:58 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Wed, 19 Jun 2019 22:40:58 +0300
SQL/JSON standard defines that jsonpath 'like_regex' predicate should support
the same set of flags as XQuery/XPath. It appears that implementation of 'q'
flag was missed. This commit fixes that.
Discussion: https://postgr.es/m/CAPpHfdtyfPsxLYiTjp5Ov8T5xGsB5t3CwE5%2B3PS%3DLLwA%2BxTJog%40mail.gmail.com
Author: Nikita Glukhov, Alexander Korotkov
M src/backend/utils/adt/jsonpath.c
M src/backend/utils/adt/jsonpath_exec.c
M src/backend/utils/adt/jsonpath_gram.y
M src/include/utils/jsonpath.h
M src/test/regress/expected/jsonb_jsonpath.out
M src/test/regress/expected/jsonpath.out
M src/test/regress/sql/jsonb_jsonpath.sql
M src/test/regress/sql/jsonpath.sql
Update list of combining characters
commit : d8594d123c155aeecd47fc2450f62f5100b2fbf0
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 19 Jun 2019 21:35:41 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 19 Jun 2019 21:35:41 +0200
The list of combining characters to ignore for calculating the display
width of a string (used for example by psql) was wildly outdated and
incorrect.
Discussion: https://www.postgresql.org/message-id/flat/bbb19114-af1e-513b-08a9-61272794bd5c%402ndquadrant.com
M src/backend/utils/mb/wchar.c
Add XSL stylesheet to fix up SVG files
commit : ac5bb8f275dd9b2746fe6d433f1c08c1c3bd3d61
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 19 Jun 2019 21:26:42 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 19 Jun 2019 21:26:42 +0200
The SVG output produced by external tools needs some postprocessing.
This is implemented by this new XSL stylesheet.
Issues are:
- SVG produced by Ditaa does not add a viewBox attribute to the svg
element, needed to make the image scalable.
- SVG produced by Graphviz uses a stroke="transparent" attribute,
which is not valid SVG. It appears to mostly work, but FOP
complains.
Other tweaks can be added over time.
This reverts 7dc78d8ef3e62f7e06d7767c63dcede048377b9a and
29046c44f36099f4c979b1491fcf27db2f9184f9, which applied these fixes
manually.
M .gitattributes
M doc/src/sgml/images/Makefile
M doc/src/sgml/images/README
A doc/src/sgml/images/fixup-svg.xsl
M doc/src/sgml/images/gin.svg
M doc/src/sgml/images/pagelayout.svg
Fix typo
commit : 66013fe73095f851c151a17ccc7553abe6246891
author : Magnus Hagander <magnus@hagander.net>
date : Wed, 19 Jun 2019 14:59:26 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Wed, 19 Jun 2019 14:59:26 +0200
Author: Daniel Gustafsson
M src/backend/access/table/tableamapi.c
Replace an occurrence of slave with standby
commit : 992fe54e77f66ed67b6480fcf7dd208b2cd28aac
author : Magnus Hagander <magnus@hagander.net>
date : Wed, 19 Jun 2019 14:38:23 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Wed, 19 Jun 2019 14:38:23 +0200
Commit a1ef920e27ba6ab3602aaf6d6751d8628fac1af8 replaced the use of
slave with standby, but overlooked this comment.
Author: Daniel Gustafsson
M contrib/pg_stat_statements/pg_stat_statements.c
Remove last references to WAL segment size in MSVC scripts
commit : 414cca40d506dd3f17b49ae3139853139192c2ba
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 19 Jun 2019 11:18:50 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 19 Jun 2019 11:18:50 +0900
fc49e24 has removed the last use of this compile-time variable as WAL
segment size is something that can now be set at initdb time, still this
commit has forgotten some references to it.
Discussion: https://postgr.es/m/20190617073228.GE18917@paquier.xyz
M src/tools/msvc/Solution.pm
Fix description of WAL record XLOG_BTREE_META_CLEANUP
commit : 3c28fd2281223580b88473e5145b752cc7cbadf9
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 19 Jun 2019 11:02:19 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 19 Jun 2019 11:02:19 +0900
This record uses one metadata buffer and registers some data associated
to the buffer, but when parsing the record for its description a direct
access to the record data was done, but there is none. This leads
usually to an incorrect description, but can also cause crashes like in
pg_waldump. Instead, fix things so as the parsing uses the data
associated to the metadata block.
This is an oversight from 3d92796, so backpatch down to 11.
Author: Michael Paquier
Description: https://postgr.es/m/20190617013059.GA3153@paquier.xyz
Backpatch-through: 11
M src/backend/access/rmgrdesc/nbtdesc.c
Fix memory corruption/crash in ANALYZE.
commit : 23224563d97913aa824d04c498d59ad4d85fda38
author : Andres Freund <andres@anarazel.de>
date : Tue, 18 Jun 2019 15:51:04 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 18 Jun 2019 15:51:04 -0700
This fixes an embarrassing oversight I (Andres) made in 737a292b,
namely missing two place where liverows/deadrows were used when
converting those variables to pointers, leading to incrementing the
pointer, rather than the value.
It's not that actually that easy to trigger a crash: One needs tuples
deleted by the current transaction, followed by a tuple deleted in
another session, all in one page. Which is presumably why this hasn't
been noticed before.
Reported-By: Steve Singer
Author: Steve Singer
Discussion: https://postgr.es/m/c7988239-d42c-ddc4-41db-171b23b35e4f@ssinger.info
M src/backend/access/heap/heapam_handler.c
M src/test/regress/expected/vacuum.out
M src/test/regress/sql/vacuum.sql
Avoid spurious deadlocks when upgrading a tuple lock
commit : 8b21b416ed621501db3be38817c298c57470524f
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 18 Jun 2019 18:23:16 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 18 Jun 2019 18:23:16 -0400
This puts back reverted commit de87a084c0a5, with some bug fixes.
When two (or more) transactions are waiting for transaction T1 to release a
tuple-level lock, and transaction T1 upgrades its lock to a higher level, a
spurious deadlock can be reported among the waiting transactions when T1
finishes. The simplest example case seems to be:
T1: select id from job where name = 'a' for key share;
Y: select id from job where name = 'a' for update; -- starts waiting for T1
Z: select id from job where name = 'a' for key share;
T1: update job set name = 'b' where id = 1;
Z: update job set name = 'c' where id = 1; -- starts waiting for T1
T1: rollback;
At this point, transaction Y is rolled back on account of a deadlock: Y
holds the heavyweight tuple lock and is waiting for the Xmax to be released,
while Z holds part of the multixact and tries to acquire the heavyweight
lock (per protocol) and goes to sleep; once T1 releases its part of the
multixact, Z is awakened only to be put back to sleep on the heavyweight
lock that Y is holding while sleeping. Kaboom.
This can be avoided by having Z skip the heavyweight lock acquisition. As
far as I can see, the biggest downside is that if there are multiple Z
transactions, the order in which they resume after T1 finishes is not
guaranteed.
Backpatch to 9.6. The patch applies cleanly on 9.5, but the new tests don't
work there (because isolationtester is not smart enough), so I'm not going
to risk it.
Author: Oleksii Kliukin
Discussion: https://postgr.es/m/B9C9D7CD-EB94-4635-91B6-E558ACEC0EC3@hintbits.com
Discussion: https://postgr.es/m/2815.1560521451@sss.pgh.pa.us
M src/backend/access/heap/README.tuplock
M src/backend/access/heap/heapam.c
A src/test/isolation/expected/tuplelock-upgrade-no-deadlock.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/tuplelock-upgrade-no-deadlock.spec
Prevent Parallel Hash Join for JOIN_UNIQUE_INNER.
commit : aca127c105aae551620d607e88d76930e6b9a2cf
author : Thomas Munro <tmunro@postgresql.org>
date : Tue, 18 Jun 2019 22:38:30 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Tue, 18 Jun 2019 22:38:30 +1200
WHERE EXISTS (...) queries cannot be executed by Parallel Hash Join
with jointype JOIN_UNIQUE_INNER, because there is no way to make a
partial plan totally unique. The consequence of allowing such plans
was duplicate results from some EXISTS queries.
Back-patch to 11. Bug #15857.
Author: Thomas Munro
Reviewed-by: Tom Lane
Reported-by: Vladimir Kriukov
Discussion: https://postgr.es/m/15857-d1ba2a64bce0795e%40postgresql.org
M src/backend/optimizer/path/joinpath.c
Stamp 12beta2.
commit : 0ab7110bcbcce5ff58afb32e7871c54e87502139
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Jun 2019 17:12:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 17 Jun 2019 17:12:29 -0400
M configure
M configure.in
M src/include/pg_config.h.win32
Translation updates
commit : 91acff7a538e6e6a8175450a38c7fa1d9a290011
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 17 Jun 2019 15:07:14 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 17 Jun 2019 15:07:14 +0200
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 1a710c413ce4c4cd081843e563cde256bb95f490
M src/backend/po/es.po
M src/backend/po/sv.po
M src/backend/po/zh_CN.po
M src/bin/initdb/po/de.po
M src/bin/initdb/po/es.po
M src/bin/initdb/po/tr.po
M src/bin/pg_archivecleanup/po/es.po
M src/bin/pg_archivecleanup/po/tr.po
M src/bin/pg_basebackup/po/de.po
M src/bin/pg_basebackup/po/es.po
M src/bin/pg_basebackup/po/tr.po
M src/bin/pg_checksums/nls.mk
A src/bin/pg_checksums/po/de.po
M src/bin/pg_checksums/po/es.po
M src/bin/pg_checksums/po/sv.po
M src/bin/pg_config/po/es.po
M src/bin/pg_config/po/zh_CN.po
M src/bin/pg_controldata/po/es.po
M src/bin/pg_controldata/po/zh_CN.po
M src/bin/pg_ctl/po/es.po
M src/bin/pg_ctl/po/zh_CN.po
M src/bin/pg_dump/po/de.po
M src/bin/pg_dump/po/es.po
M src/bin/pg_dump/po/tr.po
M src/bin/pg_resetwal/po/es.po
M src/bin/pg_resetwal/po/tr.po
M src/bin/pg_rewind/po/de.po
M src/bin/pg_rewind/po/es.po
M src/bin/pg_rewind/po/tr.po
M src/bin/pg_test_fsync/po/es.po
M src/bin/pg_test_timing/po/es.po
M src/bin/pg_upgrade/po/es.po
M src/bin/pg_waldump/po/de.po
M src/bin/pg_waldump/po/es.po
M src/bin/pg_waldump/po/sv.po
M src/bin/pg_waldump/po/tr.po
M src/bin/psql/po/es.po
M src/bin/psql/po/zh_CN.po
M src/bin/scripts/po/es.po
M src/bin/scripts/po/tr.po
M src/interfaces/ecpg/ecpglib/po/es.po
M src/interfaces/ecpg/ecpglib/po/tr.po
M src/interfaces/ecpg/ecpglib/po/zh_CN.po
M src/interfaces/ecpg/preproc/po/es.po
M src/interfaces/ecpg/preproc/po/tr.po
M src/interfaces/ecpg/preproc/po/zh_CN.po
M src/interfaces/libpq/po/es.po
M src/interfaces/libpq/po/tr.po
M src/interfaces/libpq/po/zh_CN.po
M src/pl/plperl/po/es.po
M src/pl/plperl/po/tr.po
M src/pl/plperl/po/zh_CN.po
M src/pl/plpgsql/src/po/es.po
M src/pl/plpgsql/src/po/tr.po
M src/pl/plpgsql/src/po/zh_CN.po
M src/pl/plpython/po/es.po
M src/pl/plpython/po/tr.po
M src/pl/plpython/po/zh_CN.po
M src/pl/tcl/po/es.po
M src/pl/tcl/po/tr.po
M src/pl/tcl/po/zh_CN.po
Fix buffer overflow when processing SCRAM final message in libpq
commit : b67421178880f9df337dc19b8601b54b99efbc78
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 17 Jun 2019 22:13:57 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 17 Jun 2019 22:13:57 +0900
When a client connects to a rogue server sending specifically-crafted
messages, this can suffice to execute arbitrary code as the operating
system account used by the client.
While on it, fix one error handling when decoding an incorrect salt
included in the first message received from server.
Author: Michael Paquier
Reviewed-by: Jonathan Katz, Heikki Linnakangas
Security: CVE-2019-10164
Backpatch-through: 10
M src/interfaces/libpq/fe-auth-scram.c
Fix buffer overflow when parsing SCRAM verifiers in backend
commit : 09ec55b933091cb5b0af99978718cb3d289c71b6
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 17 Jun 2019 21:48:17 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 17 Jun 2019 21:48:17 +0900
Any authenticated user can overflow a stack-based buffer by changing the
user's own password to a purpose-crafted value. This often suffices to
execute arbitrary code as the PostgreSQL operating system account.
This fix is contributed by multiple folks, based on an initial analysis
from Tom Lane. This issue has been introduced by 68e61ee, so it was
possible to make use of it at authentication time. It became more
easily to trigger after ccae190 which has made the SCRAM parsing more
strict when changing a password, in the case where the client passes
down a verifier already hashed using SCRAM. Back-patch to v10 where
SCRAM has been introduced.
Reported-by: Alexander Lakhin
Author: Jonathan Katz, Heikki Linnakangas, Michael Paquier
Security: CVE-2019-10164
Backpatch-through: 10
M src/backend/libpq/auth-scram.c
M src/test/regress/expected/password.out
M src/test/regress/sql/password.sql
Fix more typos and inconsistencies in the tree
commit : 3412030205211079f9b0510e2244083e4ee7b15a
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 17 Jun 2019 16:13:16 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 17 Jun 2019 16:13:16 +0900
Author: Alexander Lakhin
Discussion: https://postgr.es/m/0a5419ea-1452-a4e6-72ff-545b1a5a8076@gmail.com
M contrib/jsonb_plpython/jsonb_plpython.c
M contrib/pg_prewarm/autoprewarm.c
M contrib/pg_trgm/trgm_op.c
M src/backend/access/common/session.c
M src/backend/access/hash/hash.c
M src/backend/access/transam/xact.c
M src/backend/catalog/index.c
M src/backend/catalog/partition.c
M src/backend/commands/copy.c
M src/backend/commands/functioncmds.c
M src/backend/executor/execMain.c
M src/backend/executor/execUtils.c
M src/backend/executor/nodeHash.c
M src/backend/executor/nodeProjectSet.c
M src/backend/jit/llvm/Makefile
M src/backend/lib/integerset.c
M src/backend/libpq/pqformat.c
M src/backend/replication/walsender.c
M src/backend/statistics/mcv.c
M src/backend/storage/file/fd.c
M src/backend/storage/file/sharedfileset.c
M src/backend/storage/ipc/barrier.c
M src/backend/storage/ipc/shm_mq.c
M src/backend/utils/Gen_fmgrtab.pl
M src/backend/utils/adt/jsonfuncs.c
M src/backend/utils/sort/sharedtuplestore.c
M src/bin/pg_dump/common.c
M src/include/access/xlogdefs.h
M src/include/catalog/partition.h
M src/include/catalog/pg_foreign_data_wrapper.h
M src/include/executor/tuptable.h
M src/include/optimizer/placeholder.h
M src/include/partitioning/partprune.h
M src/include/port/pg_bitutils.h
M src/include/utils/jsonapi.h
M src/include/utils/sharedtuplestore.h
M src/pl/plperl/plperl.h
M src/port/pwrite.c
M src/test/isolation/specs/partition-key-update-4.spec
M src/test/modules/test_integerset/README
M src/tools/msvc/config_default.pl
Revert "Avoid spurious deadlocks when upgrading a tuple lock"
commit : 9d20b0ec8f2af43041b1a65e5fcd91acc47e9ace
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sun, 16 Jun 2019 22:24:21 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sun, 16 Jun 2019 22:24:21 -0400
This reverts commits 3da73d6839dc and de87a084c0a5.
This code has some tricky corner cases that I'm not sure are correct and
not properly tested anyway, so I'm reverting the whole thing for next
week's releases (reintroducing the deadlock bug that we set to fix).
I'll try again afterwards.
Discussion: https://postgr.es/m/E1hbXKQ-0003g1-0C@gemulon.postgresql.org
M src/backend/access/heap/README.tuplock
M src/backend/access/heap/heapam.c
D src/test/isolation/expected/tuplelock-upgrade-no-deadlock.out
M src/test/isolation/isolation_schedule
D src/test/isolation/specs/tuplelock-upgrade-no-deadlock.spec
Doc: remove description of commit 23bd3cec6 from v12 release notes.
commit : 16c4e76f1b0a0145572551b7e919b967e406a0b1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 16 Jun 2019 14:02:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 16 Jun 2019 14:02:22 -0400
Now that we've back-patched that, it shouldn't be mentioned in v12
anymore.
M doc/src/sgml/release-12.sgml
Further fix privileges on pg_statistic_ext[_data].
commit : 6973b058bc8d32e104bed99c134a4fab4b5dfe13
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 16 Jun 2019 11:00:23 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 16 Jun 2019 11:00:23 -0400
We don't need to restrict column privileges on pg_statistic_ext;
all of that data is OK to read publicly. What we *do* need to do,
which was overlooked by 6cbfb784c, is revoke public read access on
pg_statistic_ext_data; otherwise we still have the same security
hole we started with.
Catversion bump to ensure that installations calling themselves
beta2 will have this fix.
Diagnosis/correction by Dean Rasheed and Tomas Vondra, but I'm
going to go ahead and push this fix ASAP so we get more buildfarm
cycles on it.
Discussion: https://postgr.es/m/8833.1560647898@sss.pgh.pa.us
M src/backend/catalog/system_views.sql
M src/include/catalog/catversion.h
Fix privileges on pg_statistic_ext.tableoid
commit : fc8cf3df478e054b892f6698b6d336e72f3a7328
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Sun, 16 Jun 2019 12:04:40 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Sun, 16 Jun 2019 12:04:40 +0200
The GRANT in system_views allowed SELECT privileges on various columns in
the pg_statistic_ext catalog, but tableoid was not included in the list.
That made pg_dump fail because it's accessing this column when building
the list of extended statistics to dump.
Discussion: https://postgr.es/m/8833.1560647898%40sss.pgh.pa.us
M src/backend/catalog/system_views.sql
Fix incorrect CREATE STATISTICS example in docs
commit : 7f44efa10b6ea3e5fd125e2800f357f38ab1068c
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Sat, 15 Jun 2019 21:38:53 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Sat, 15 Jun 2019 21:38:53 +0200
The example was incorrectly using parantheses around the list of columns, so
just drop them.
Reported-By: Robert Haas
Discussion: https://postgr.es/m/CA%2BTgmoZZEMAqWMAfvLHZnK57SoxOutgvE-ALO94WsRA7zZ7wyQ%40mail.gmail.com
M doc/src/sgml/ref/create_statistics.sgml
Add pg_stats_ext view for extended statistics
commit : aa087ec64f703a52f3c48c70117bb02e578f1802
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Thu, 13 Jun 2019 17:25:04 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Thu, 13 Jun 2019 17:25:04 +0200
Regular per-column statistics are stored in pg_statistics catalog, which
is however rather difficult to read, so we also have pg_stats view with
a human-reablable version of the data.
For extended statistic the catalog was fairly easy to read, so we did
not have such human-readable view so far. Commit 9b6babfa2d however did
split the catalog into two, which makes querying harder. Furthermore,
we want to show the multi-column MCV list in a way similar to per-column
stats (and not as a bytea value).
This commit introduces pg_stats_ext view, joining the two catalogs and
massaging the data to produce human-readable output similar to pg_stats.
It also considers RLS and access privileges - the data is shown only when
the user has access to all columns the extended statistic is defined on.
Bumped CATVERSION due to adding new system view.
Author: Dean Rasheed, with improvements by me
Reviewed-by: Dean Rasheed, John Naylor
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
M doc/src/sgml/catalogs.sgml
M src/backend/catalog/system_views.sql
M src/include/catalog/catversion.h
M src/test/regress/expected/rules.out
Rework the pg_statistic_ext catalog
commit : 6cbfb784c3c91146148a76d50cda6f69ae6a79fb
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Thu, 13 Jun 2019 17:19:21 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Thu, 13 Jun 2019 17:19:21 +0200
Since extended statistic got introduced in PostgreSQL 10, there was a
single catalog pg_statistic_ext storing both the definitions and built
statistic. That's however problematic when a user is supposed to have
access only to the definitions, but not to user data.
Consider for example pg_dump on a database with RLS enabled - if the
pg_statistic_ext catalog respects RLS (which it should, if it contains
user data), pg_dump would not see any records and the result would not
define any extended statistics. That would be a surprising behavior.
Until now this was not a pressing issue, because the existing types of
extended statistic (functional dependencies and ndistinct coefficients)
do not include any user data directly. This changed with introduction
of MCV lists, which do include most common combinations of values.
The easiest way to fix this is to split the pg_statistic_ext catalog
into two - one for definitions, one for the built statistic values.
The new catalog is called pg_statistic_ext_data, and we're maintaining
a 1:1 relationship with the old catalog - either there are matching
records in both catalogs, or neither of them.
Bumped CATVERSION due to changing system catalog definitions.
Author: Dean Rasheed, with improvements by me
Reviewed-by: Dean Rasheed, John Naylor
Discussion: https://postgr.es/m/CAEZATCUhT9rt7Ui%3DVdx4N%3D%3DVV5XOK5dsXfnGgVOz_JhAicB%3DZA%40mail.gmail.com
M doc/src/sgml/catalogs.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/perform.sgml
M doc/src/sgml/planstats.sgml
M src/backend/catalog/Makefile
M src/backend/commands/statscmds.c
M src/backend/optimizer/util/plancat.c
M src/backend/statistics/README.mcv
M src/backend/statistics/dependencies.c
M src/backend/statistics/extended_stats.c
M src/backend/statistics/mcv.c
M src/backend/statistics/mvdistinct.c
M src/backend/utils/cache/syscache.c
M src/include/catalog/catversion.h
M src/include/catalog/indexing.h
M src/include/catalog/pg_statistic_ext.h
A src/include/catalog/pg_statistic_ext_data.h
M src/include/catalog/toasting.h
M src/include/utils/syscache.h
M src/test/regress/expected/oidjoins.out
M src/test/regress/expected/sanity_check.out
M src/test/regress/expected/stats_ext.out
M src/test/regress/sql/oidjoins.sql
M src/test/regress/sql/stats_ext.sql
M src/tools/pgindent/typedefs.list
Prefer timezone name "UTC" over alternative spellings.
commit : e3846a00c2f87402dcedf7f07950ab2d89cf5827
author : Andrew Gierth <rhodiumtoad@postgresql.org>
date : Sat, 15 Jun 2019 18:15:23 +0100
committer: Andrew Gierth <rhodiumtoad@postgresql.org>
date : Sat, 15 Jun 2019 18:15:23 +0100
tzdb 2019a made "UCT" a link to the "UTC" zone rather than a separate
zone with its own abbreviation. Unfortunately, our code for choosing a
timezone in initdb has an arbitrary preference for names earlier in
the alphabet, and so it would choose the spelling "UCT" over "UTC"
when the system is running on a UTC zone.
Commit 23bd3cec6 was backpatched in order to address this issue, but
that code helps only when /etc/localtime exists as a symlink, and does
nothing to help on systems where /etc/localtime is a copy of a zone
file (as is the standard setup on FreeBSD and probably some other
platforms too) or when /etc/localtime is simply absent (giving UTC as
the default).
Accordingly, add a preference for the spelling "UTC", such that if
multiple zone names have equally good content matches, we prefer that
name before applying the existing arbitrary rules. Also add a slightly
lower preference for "Etc/UTC"; lower because that preserves the
previous behaviour of choosing the shorter name, but letting us still
choose "Etc/UTC" over "Etc/UCT" when both exist but "UTC" does
not (not common, but I've seen it happen).
Backpatch all the way, because the tzdb change that sparked this issue
is in those branches too.
M src/bin/initdb/findtimezone.c
Add pg_dumpall --rows-per-insert
commit : a193cbec1199e4e529c46645b7aecbf38956048b
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 14 Jun 2019 18:21:52 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 14 Jun 2019 18:21:52 -0400
Commit 7e413a0f82c8 added that option to pg_dump, but neglected to teach
pg_dumpall how to pass it along. Repair.
Author: Fabien Coelho
Reported-by: Peter Eisentraut
Reviewed-by: David Rowley
Discussion: https://postgr.es/m/45f50c59-ddbb-8cf2-eedb-81003f603528@2ndquadrant.com
M doc/src/sgml/ref/pg_dumpall.sgml
M src/bin/pg_dump/pg_dumpall.c
Tweak libpq's PQhost, PQhostaddr, and psql's \connect
commit : 313f56ce2d1b9dfd3483e4f39611baa27852835a
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 14 Jun 2019 18:02:26 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 14 Jun 2019 18:02:26 -0400
Fixes some problems introduced by 6e5f8d489acc:
* When reusing conninfo data from the previous connection in \connect,
the host address should only be reused if it was specified as
hostaddr; if it wasn't, then 'host' is resolved afresh. We were
reusing the same IP address, which ignores a possible DNS change
as well as any other addresses that the name resolves to than the
one that was used in the original connection.
* PQhost, PQhostaddr: Don't present user-specified hostaddr when we have
an inet_net_ntop-produced equivalent address. The latter has been
put in canonical format, which is cleaner (so it produces "127.0.0.1"
when given "host=2130706433", for example).
* Document the hostaddr-reusing aspect of \connect.
* Fix some code comments
Author: Fabien Coelho
Reported-by: Noah Misch
Discussion: https://postgr.es/m/20190527203713.GA58392@gust.leadboat.com
M doc/src/sgml/ref/psql-ref.sgml
M src/bin/psql/command.c
M src/interfaces/libpq/fe-connect.c
Silence compiler warning
commit : 3da73d6839dc47f1f47ca57974bf28e5abd9b572
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 14 Jun 2019 11:33:40 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 14 Jun 2019 11:33:40 -0400
Introduced in de87a084c0a5.
M src/backend/access/heap/heapam.c
doc: PG 12 relnotes, add mention of single-child optimization
commit : b9a0724cf7a3ecf19aaaa098ffd26e52bb800c5c
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 14 Jun 2019 09:30:31 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 14 Jun 2019 09:30:31 -0400
Add mention of single-child optimization for partitions and UNION ALL.
Reported-by: David Rowley
Discussion: https://postgr.es/m/CAKJS1f8R8riwBXw==7ijV=UZNuhP+3qXgDBKSiM+=_cTf4mXXw@mail.gmail.com
M doc/src/sgml/release-12.sgml
postgres_fdw: Fix costing of pre-sorted foreign paths with local stats.
commit : 08d2d58a2a1c8ef8d39e8132d39ee14a1d029500
author : Etsuro Fujita <efujita@postgresql.org>
date : Fri, 14 Jun 2019 20:49:59 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Fri, 14 Jun 2019 20:49:59 +0900
Commit aa09cd242 modified estimate_path_cost_size() so that it reuses
cached costs of a basic foreign path for a given foreign-base/join
relation when costing pre-sorted foreign paths for that relation, but it
incorrectly re-computed retrieved_rows, an estimated number of rows
fetched from the remote side, which is needed for costing both the basic
and pre-sorted foreign paths. To fix, handle retrieved_rows the same way
as the cached costs: store in that relation's fpinfo the retrieved_rows
estimate computed for costing the basic foreign path, and reuse it when
costing the pre-sorted foreign paths. Also, reuse the rows/width
estimates stored in that relation's fpinfo when costing the pre-sorted
foreign paths, to make the code consistent.
In commit ffab494a4, to extend the costing mentioned above to the
foreign-grouping case, I made a change to add_foreign_grouping_paths() to
store in a given foreign-grouped relation's RelOptInfo the rows estimate
for that relation for reuse, but this patch makes that change unnecessary
since we already store the row estimate in that relation's fpinfo, which
this patch reuses when costing a foreign path for that relation with the
sortClause ordering; remove that change.
In passing, fix thinko in commit 7012b132d: in estimate_path_cost_size(),
the width estimate for a given foreign-grouped relation to be stored in
that relation's fpinfo was reset incorrectly when costing a basic foreign
path for that relation with local stats.
Apply the patch to HEAD only to avoid destabilizing existing plan choices.
Author: Etsuro Fujita
Discussion: https://postgr.es/m/CAPmGK17jaJLPDEkgnP2VmkOg=5wT8YQ1CqssU8JRpZ_NSE+dqQ@mail.gmail.com
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/postgres_fdw.h
docs: PG 12 relnotes, update self-join item to mention ctid
commit : be2e024bd6527b050da4ad02c921869fed84bb5d
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 13 Jun 2019 22:53:20 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 13 Jun 2019 22:53:20 -0400
Reported-by: Robert Haas
Discussion: https://postgr.es/m/CA+TgmoY==TZwk-4cM3Usebq1f=j7Hpm1brFbk1v48h45wsWzzg@mail.gmail.com
M doc/src/sgml/release-12.sgml
docs: PG 12 relnotes, move vacuumdb to the client app section
commit : 18ef7a34fe616dc63f7de672a5ab7dd88137dc5c
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 13 Jun 2019 22:07:25 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 13 Jun 2019 22:07:25 -0400
It was previously incorrectly placed in the server application section.
Reported-by: Tatsuo Ishii
Discussion: https://postgr.es/m/20190526.215341.1023150119477784132.t-ishii@sraoss.co.jp
M doc/src/sgml/release-12.sgml
Fix typos and inconsistencies in code comments
commit : f43608bda2111a1fda514d1bed4df313ee2bbec3
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 14 Jun 2019 09:34:34 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 14 Jun 2019 09:34:34 +0900
Author: Alexander Lakhin
Discussion: https://postgr.es/m/dec6aae8-2d63-639f-4d50-20e229fb83e3@gmail.com
M src/backend/access/nbtree/nbtsearch.c
M src/backend/catalog/catalog.c
M src/backend/commands/copy.c
M src/backend/libpq/be-secure-gssapi.c
M src/backend/parser/parse_target.c
M src/backend/postmaster/checkpointer.c
M src/backend/utils/cache/lsyscache.c
M src/port/pg_bitutils.c
Use OpenSSL-specific ifdefs in sha2.h
commit : 96719e52b1abd3a8c712d06a809b7e6c97c2e3a0
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 14 Jun 2019 09:00:36 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 14 Jun 2019 09:00:36 +0900
In order to separate OpenSSL's SHA symbols, this header has been using
USE_SSL, which is equivalent to USE_OPENSSL. There is now only one SSL
implementation included in the tree, so this works fine, but when
adding a new SSL implementation this would run into failures.
Author: Daniel Gustafsson
Discussion: https://postgr.es/m/0DF29010-CE26-4F51-85A6-9C8ABF5536F9@yesql.se
M src/include/common/sha2.h
Avoid combinatorial explosion in add_child_rel_equivalences().
commit : d25ea0127598dd0ad27a029215172f396fbd1009
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 13 Jun 2019 18:10:08 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 13 Jun 2019 18:10:08 -0400
If an EquivalenceClass member expression includes variables from
multiple appendrels, then instead of producing one substituted
expression per child relation as intended, we'd create additional
child expressions for combinations of children of different appendrels.
This happened because the child expressions generated while considering
the first appendrel were taken as sources during substitution of the
second appendrel, and so on. The extra expressions are useless, and are
harmless unless there are too many of them --- but if you have several
appendrels with a thousand or so members each, it gets bad fast.
To fix, consider only original (non-em_is_child) EC members as candidates
to be expanded. This requires the ability to substitute directly from a
top parent relation's Vars to those of an indirect descendant relation,
but we already have that in adjust_appendrel_attrs_multilevel().
Per bug #15847 from Feike Steenbergen. This is a longstanding misbehavior,
but it's only worth worrying about when there are more appendrel children
than we've historically considered wise to use. So I'm not going to take
the risk of back-patching this.
Discussion: https://postgr.es/m/15847-ea3734094bf8ae61@postgresql.org
M src/backend/optimizer/path/equivclass.c
Avoid spurious deadlocks when upgrading a tuple lock
commit : de87a084c0a5ac927017cd0834b33a932651cfc9
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 13 Jun 2019 17:28:24 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 13 Jun 2019 17:28:24 -0400
When two (or more) transactions are waiting for transaction T1 to release a
tuple-level lock, and transaction T1 upgrades its lock to a higher level, a
spurious deadlock can be reported among the waiting transactions when T1
finishes. The simplest example case seems to be:
T1: select id from job where name = 'a' for key share;
Y: select id from job where name = 'a' for update; -- starts waiting for X
Z: select id from job where name = 'a' for key share;
T1: update job set name = 'b' where id = 1;
Z: update job set name = 'c' where id = 1; -- starts waiting for X
T1: rollback;
At this point, transaction Y is rolled back on account of a deadlock: Y
holds the heavyweight tuple lock and is waiting for the Xmax to be released,
while Z holds part of the multixact and tries to acquire the heavyweight
lock (per protocol) and goes to sleep; once X releases its part of the
multixact, Z is awakened only to be put back to sleep on the heavyweight
lock that Y is holding while sleeping. Kaboom.
This can be avoided by having Z skip the heavyweight lock acquisition. As
far as I can see, the biggest downside is that if there are multiple Z
transactions, the order in which they resume after X finishes is not
guaranteed.
Backpatch to 9.6. The patch applies cleanly on 9.5, but the new tests don't
work there (because isolationtester is not smart enough), so I'm not going
to risk it.
Author: Oleksii Kliukin
Discussion: https://postgr.es/m/B9C9D7CD-EB94-4635-91B6-E558ACEC0EC3@hintbits.com
M src/backend/access/heap/README.tuplock
M src/backend/access/heap/heapam.c
A src/test/isolation/expected/tuplelock-upgrade-no-deadlock.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/tuplelock-upgrade-no-deadlock.spec
Mark ReplicationSlotCtl as PGDLLIMPORT.
commit : 3c8f8f6ebefb3c2debd1cad1ba445a729290dac7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 13 Jun 2019 10:53:17 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 13 Jun 2019 10:53:17 -0400
Also MyReplicationSlot, in branches where it wasn't already.
This was discussed in the thread that resulted in c572599c6, but
for some reason nobody pulled the trigger. Now that we have another
request for the same thing, we should just do it.
Craig Ringer
Discussion: https://postgr.es/m/CAMsr+YFTsq-86MnsNng=mPvjjh5EAbzfMK0ptJPvzyvpFARuRg@mail.gmail.com
Discussion: https://postgr.es/m/345138875.20190611151943@cybertec.at
M src/include/replication/slot.h
Fix double-word typos
commit : b9768458154de6c001af23efc02514f120c6094f
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 12 Jun 2019 14:16:18 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 12 Jun 2019 14:16:18 -0400
Discussion: https://postgr.es/m/20190612184527.GA24266@alvherre.pgsql
Reviewed-by: Michaël Paquier
M doc/src/sgml/backup.sgml
M src/bin/pg_dump/pg_dump.c
M src/include/executor/tuptable.h
M src/include/fmgr.h
M src/include/utils/snapshot.h
M src/interfaces/ecpg/preproc/type.c
M src/test/modules/test_integerset/test_integerset.c
M src/test/recovery/t/013_crash_restart.pl
M src/test/regress/expected/polygon.out
M src/test/regress/sql/polygon.sql
doc: PG 12 relnotes: update wording on truncate/vacuum item
commit : 4f41a7227511a3f96148b7f3d4ae6f0c350bc7b2
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 13 Jun 2019 09:15:57 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 13 Jun 2019 09:15:57 -0400
This item prevents unauthorized locking of relations, and the previous
wording was unclear.
Reported-by: Michael Paquier
Discussion: https://postgr.es/m/20190522072651.GC1278@paquier.xyz
M doc/src/sgml/release-12.sgml
postgres_fdw: Account for triggers in non-direct remote UPDATE planning.
commit : 8b6da83d162cb0ac9f6d21082727bbd45c972c53
author : Etsuro Fujita <efujita@postgresql.org>
date : Thu, 13 Jun 2019 17:59:09 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Thu, 13 Jun 2019 17:59:09 +0900
Previously, in postgresPlanForeignModify, we planned an UPDATE operation
on a foreign table so that we transmit only columns that were explicitly
targets of the UPDATE, so as to avoid unnecessary data transmission, but
if there were BEFORE ROW UPDATE triggers on the foreign table, those
triggers might change values for non-target columns, in which case we
would miss sending changed values for those columns. Prevent optimizing
away transmitting all columns if there are BEFORE ROW UPDATE triggers on
the foreign table.
This is an oversight in commit 7cbe57c34 which added triggers on foreign
tables, so apply the patch all the way back to 9.4 where that came in.
Author: Shohei Mochizuki
Reviewed-by: Amit Langote
Discussion: https://postgr.es/m/201905270152.x4R1q3qi014550@toshiba.co.jp
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/sql/postgres_fdw.sql
Doc: fix bogus example.
commit : 7dc6ae37def50b5344c157eee5e029a09359f8ee
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 12 Jun 2019 23:05:40 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 12 Jun 2019 23:05:40 -0400
This wasn't incorrect SQL, but it was doing cm-to-inch conversion
backward, so it might confuse readers.
Per bug #15849 from TAKATSUKA Haruka.
Discussion: https://postgr.es/m/15849-37ad0c561a836107@postgresql.org
M doc/src/sgml/ddl.sgml
Doc: improve description of allowed spellings for Boolean input.
commit : 9729c9360886bee7feddc6a1124b0742de4b9f3d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 12 Jun 2019 22:54:46 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 12 Jun 2019 22:54:46 -0400
datatype.sgml failed to explain that boolin() accepts any unique
prefix of the basic input strings. Indeed it was actively misleading
because it called out a few minimal prefixes without mentioning that
there were more valid inputs.
I also felt that it wasn't doing anybody any favors by conflating
SQL key words, valid Boolean input, and string literals containing
valid Boolean input. Rewrite in hopes of reducing the confusion.
Per bug #15836 from Yuming Wang, as diagnosed by David Johnston.
Back-patch to supported branches.
Discussion: https://postgr.es/m/15836-656fab055735f511@postgresql.org
M doc/src/sgml/datatype.sgml
docs: PG 12 relnotes, update btree items
commit : 4bfb79ff6b1fd400b3dbc761921472173675a968
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 12 Jun 2019 22:48:04 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 12 Jun 2019 22:48:04 -0400
Reported-by: Peter Geoghegan
Discussion: https://postgr.es/m/CAH2-Wzn-aH4ToZEWR05ELSSp7bO_JMn=sMPfUhNruwVmCXKh-w@mail.gmail.com
M doc/src/sgml/release-12.sgml
Fix incorrect printing of queries with duplicated join names.
commit : 3d99a81397abb8bb7b95aee794d6644e174e174f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 12 Jun 2019 19:42:38 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 12 Jun 2019 19:42:38 -0400
Given a query in which multiple JOIN nodes used the same alias
(which'd necessarily be in different sub-SELECTs), ruleutils.c
would assign the JOIN nodes distinct aliases for clarity ...
but then it forgot to print the modified aliases when dumping
the JOIN nodes themselves. This results in a dump/reload hazard
for views, because the emitted query is flat-out incorrect:
Vars will be printed with table names that have no referent.
This has been wrong for a long time, so back-patch to all supported
branches.
Philip Dubé
Discussion: https://postgr.es/m/CY4PR2101MB080246F2955FF58A6ED1FEAC98140@CY4PR2101MB0802.namprd21.prod.outlook.com
M src/backend/utils/adt/ruleutils.c
M src/test/regress/expected/create_view.out
M src/test/regress/sql/create_view.sql
doc: Fix grammatical error in partitioning docs
commit : ddc053dc503a773267a4d035418e0c81ce3b4851
author : David Rowley <drowley@postgresql.org>
date : Thu, 13 Jun 2019 10:35:11 +1200
committer: David Rowley <drowley@postgresql.org>
date : Thu, 13 Jun 2019 10:35:11 +1200
Reported-by: Amit Langote
Discussion: https://postgr.es/m/CA+HiwqGZFkKi0TkBGYpr2_5qrRAbHZoP47AP1BRLUOUkfQdy_A@mail.gmail.com
Backpatch-through: 10
M doc/src/sgml/ddl.sgml
doc: PG 12 relnotes, list added snowball/FTS languages
commit : 968072837173a0c0fa426114b17177f997b85473
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 12 Jun 2019 17:46:38 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 12 Jun 2019 17:46:38 -0400
Reported-by: Adrien Nayrat
Discussion: https://postgr.es/m/9d6a7515-bcd8-05be-d2a5-e81dc11023cd@anayrat.info
M doc/src/sgml/release-12.sgml
doc: PG 12 relnotes, merge new SQL partition function items
commit : 6a631a454664c145b7da88c9ef3976f8ac3ab0b1
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 12 Jun 2019 17:36:43 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 12 Jun 2019 17:36:43 -0400
Reported-by: Andres Freund
Discussion: https://postgr.es/m/20190528155823.3e4cezblxjxotq2q@alap3.anarazel.de
M doc/src/sgml/release-12.sgml
Fix ALTER COLUMN TYPE failure with a partial exclusion constraint.
commit : e76de886157b7f974d4d247908b242607cfbf043
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 12 Jun 2019 12:29:24 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 12 Jun 2019 12:29:24 -0400
ATExecAlterColumnType failed to consider the possibility that an index
that needs to be rebuilt might be a child of a constraint that needs to be
rebuilt. We missed this so far because usually a constraint index doesn't
have a direct dependency on its table, just on the constraint object.
But if there's a WHERE clause, then dependency analysis of the WHERE
clause results in direct dependencies on the column(s) mentioned in WHERE.
This led to trying to drop and rebuild both the constraint and its
underlying index.
In v11/HEAD, we successfully drop both the index and the constraint,
and then try to rebuild both, and of course the second rebuild hits a
duplicate-index-name problem. Before v11, it fails with obscure messages
about a missing relation OID, due to trying to drop the index twice.
This is essentially the same kind of problem noted in commit
20bef2c31: the possible dependency linkages are broader than what
ATExecAlterColumnType was designed for. It was probably OK when
written, but it's certainly been broken since the introduction of
partial exclusion constraints. Fix by adding an explicit check
for whether any of the indexes-to-be-rebuilt belong to any of the
constraints-to-be-rebuilt, and ignoring any that do.
In passing, fix a latent bug introduced by commit 8b08f7d48: in
get_constraint_index() we must "continue" not "break" when rejecting
a relation of a wrong relkind. This is harmless today because we don't
expect that code path to be taken anyway; but if there ever were any
relations to be ignored, the existing coding would have an extremely
undesirable dependency on the order of pg_depend entries.
Also adjust a couple of obsolete comments.
Per bug #15835 from Yaroslav Schekin. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/15835-32d9b7a76c06a7a9@postgresql.org
M src/backend/catalog/pg_depend.c
M src/backend/commands/tablecmds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Fix handling of COMMENT for domain constraints
commit : ceac4505d3428a8414b4f3d6708ea81506811a5f
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 12 Jun 2019 11:30:11 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 12 Jun 2019 11:30:11 +0900
For a non-superuser, changing a comment on a domain constraint was
leading to a cache lookup failure as the code tried to perform the
ownership lookup on the constraint OID itself, thinking that it was a
type, but this check needs to happen on the type the domain constraint
relies on. As the type a domain constraint relies on can be guessed
directly based on the constraint OID, first fetch its type OID and
perform the ownership on it.
This is broken since 7eca575, which has split the handling of comments
for table constraints and domain constraints, so back-patch down to
9.5.
Reported-by: Clemens Ladisch
Author: Daniel Gustafsson, Michael Paquier
Reviewed-by: Álvaro Herrera
Discussion: https://postgr.es/m/15833-808e11904835d26f@postgresql.org
Backpatch-through: 9.5
M src/backend/catalog/objectaddress.c
M src/test/regress/input/constraints.source
M src/test/regress/output/constraints.source
doc: Add best practises section to partitioning docs
commit : e788e849addd56007a0e75f3b5514f294a0f3bca
author : David Rowley <drowley@postgresql.org>
date : Wed, 12 Jun 2019 08:08:57 +1200
committer: David Rowley <drowley@postgresql.org>
date : Wed, 12 Jun 2019 08:08:57 +1200
A few questionable partitioning designs have been cropping up lately
around the mailing lists. Generally, these cases have been partitioning
using too many partitions which have caused performance or OOM problems for
the users.
Since we have very little else to guide users into good design, here we
add a new section to the partitioning documentation with some best
practise guidelines for good design.
Reviewed-by: Justin Pryzby, Amit Langote, Alvaro Herrera
Discussion: https://postgr.es/m/CAKJS1f-2rx+E9mG3xrCVHupefMjAp1+tpczQa9SEOZWyU7fjEA@mail.gmail.com
Backpatch-through: 10
M doc/src/sgml/ddl.sgml
Fix conversion of JSON strings to JSON output columns in json_to_record().
commit : 6f34fcbbd5ad5a6546710e7b90e6331cacfd36dc
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 11 Jun 2019 13:33:08 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 11 Jun 2019 13:33:08 -0400
json_to_record(), when an output column is declared as type json or jsonb,
should emit the corresponding field of the input JSON object. But it got
this slightly wrong when the field is just a string literal: it failed to
escape the contents of the string. That typically resulted in syntax
errors if the string contained any double quotes or backslashes.
jsonb_to_record() handles such cases correctly, but I added corresponding
test cases for it too, to prevent future backsliding.
Improve the documentation, as it provided only a very hand-wavy
description of the conversion rules used by these functions.
Per bug report from Robert Vollmert. Back-patch to v10 where the
error was introduced (by commit cf35346e8).
Note that PG 9.4 - 9.6 also get this case wrong, but differently so:
they feed the de-escaped contents of the string literal to json[b]_in.
That behavior is less obviously wrong, so possibly it's being depended on
in the field, so I won't risk trying to make the older branches behave
like the newer ones.
Discussion: https://postgr.es/m/D6921B37-BD8E-4664-8D5F-DB3525765DCD@vllmrt.net
M doc/src/sgml/func.sgml
M src/backend/utils/adt/jsonfuncs.c
M src/test/regress/expected/json.out
M src/test/regress/expected/jsonb.out
M src/test/regress/sql/json.sql
M src/test/regress/sql/jsonb.sql
Fix order of steps in DISCARD ALL documentation
commit : 9f05c44ba4a4a6a857b957734bb369a2bb4dd62b
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 11 Jun 2019 12:22:11 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 11 Jun 2019 12:22:11 -0400
The docs have always been slightly inaccurate, but got particularly so
in a874fe7b4c89, which made DISCARD ALL occur before everything else;
reorder.
Author: Jan Chochol
Discussion: https://postgr.es/m/CAEASf_3TzBbnXm64HpnD5zCZEh8An9jN8ubMR=De-vOXHMHGeA@mail.gmail.com
M doc/src/sgml/ref/discard.sgml
Don't access catalogs to validate GUCs when not connected to a DB.
commit : fff2a7d7bd09db38e1bafc1303c29b10a9805dc0
author : Andres Freund <andres@anarazel.de>
date : Mon, 10 Jun 2019 23:20:48 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 10 Jun 2019 23:20:48 -0700
Vignesh found this bug in the check function for
default_table_access_method's check hook, but that was just copied
from older GUCs. Investigation by Michael and me then found the bug in
further places.
When not connected to a database (e.g. in a walsender connection), we
cannot perform (most) GUC checks that need database access. Even when
only shared tables are needed, unless they're
nailed (c.f. RelationCacheInitializePhase2()), they cannot be accessed
without pg_class etc. being present.
Fix by extending the existing IsTransactionState() checks to also
check for MyDatabaseOid.
Reported-By: Vignesh C, Michael Paquier, Andres Freund
Author: Vignesh C, Andres Freund
Discussion: https://postgr.es/m/CALDaNm1KXK9gbZfY-p_peRFm_XrBh1OwQO1Kk6Gig0c0fVZ2uw%40mail.gmail.com
Backpatch: 9.4-
M src/backend/access/table/tableamapi.c
M src/backend/commands/tablespace.c
M src/backend/utils/cache/ts_cache.c
postgres_fdw: Reorder C includes.
commit : 92a88644d2b7208e98d9e913c3a574c5c2fe7b78
author : Etsuro Fujita <efujita@postgresql.org>
date : Tue, 11 Jun 2019 13:39:31 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Tue, 11 Jun 2019 13:39:31 +0900
Reorder header files in postgres_fdw.c and connection.c in alphabetical
order.
Author: Etsuro Fujita
Reviewed-by: Alvaro Herrera
Discussion: https://postgr.es/m/CAPmGK17ZmNb-EELqu8LmMh2t2uFdbfWNVDEfDO5-bpejHPONMQ@mail.gmail.com
M contrib/postgres_fdw/connection.c
M contrib/postgres_fdw/postgres_fdw.c
Fix documentation of ALTER TABLE for stored values
commit : 727e45c8a457ab7378494ff33bf3b50607d303a8
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 11 Jun 2019 12:58:51 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 11 Jun 2019 12:58:51 +0900
Author: Masahiko Sawada
Discussion: https://postgr.es/m/CAD21AoAA_gvZ002U6kovOHu0FsM7ieoCzdSqWBd7_KaQL0UMKg@mail.gmail.com
M doc/src/sgml/ref/alter_table.sgml
tableam: Fix index_build_range_scan parameter name.
commit : 132a1c101a205ee52ec7d731abcb8593a6354097
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 10 Jun 2019 20:04:44 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 10 Jun 2019 20:04:44 -0400
All of the other code thinks that the 8th parameter is the number of
blocks, but this declaration thinks that it's the ending block number.
Repair this inconsistency.
Patch by me, reviewed by Andres Freund.
Discussion: http://postgr.es/m/CA+TgmoY49ManQWnJtiwkuytXBkmyTuDFqb74Pr4Zn2Nq9TuNBQ@mail.gmail.com
M src/include/access/tableam.h
Make pg_dump emit ATTACH PARTITION instead of PARTITION OF (reprise)
commit : 33a53130a89447e171a8268ae0b221bb48af6468
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 10 Jun 2019 18:56:23 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 10 Jun 2019 18:56:23 -0400
Using PARTITION OF can result in column ordering being changed from the
database being dumped, if the partition uses a column layout different
from the parent's. It's not pg_dump's job to editorialize on table
definitions, so this is not acceptable; back-patch all the way back to
pg10, where partitioned tables where introduced.
This change also ensures that partitions end up in the correct
tablespace, if different from the parent's; this is an oversight in
ca4103025dfe (in pg12 only). Partitioned indexes (in pg11) don't have
this problem, because they're already created as independent indexes and
attached to their parents afterwards.
This change also has the advantage that the partition is restorable from
the dump (as a standalone table) even if its parent table isn't
restored.
The original commits (3b23552ad8bb in branch master) failed to cover
subsidiary column elements correctly, such as NOT NULL constraint and
CHECK constraints, as reported by Rushabh Lathia (initially as a failure
to restore serial columns). They were reverted. This recapitulation
commit fixes those problems.
Add some pg_dump tests to verify these things more exhaustively,
including constraints with legacy-inheritance tables, which were not
tested originally. In branches 10 and 11, add a local constraint to the
pg_dump test partition that was added by commit 2d7eeb1b1492 to master.
Author: Álvaro Herrera, David Rowley
Reviewed-by: Álvaro Herrera
Discussion: https://postgr.es/m/CAKJS1f_1c260nOt_vBJ067AZ3JXptXVRohDVMLEBmudX1YEx-A@mail.gmail.com
Discussion: https://postgr.es/m/20190423185007.GA27954@alvherre.pgsql
Discussion: https://postgr.es/m/CAGPqQf0iQV=PPOv2Btog9J9AwOQp6HmuVd6SbGTR_v3Zp2XT1w@mail.gmail.com
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/t/002_pg_dump.pl
Fix operator naming in pg_trgm GUC option descriptions
commit : b6987a885ba9216e1f4319441303ee115556922c
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 10 Jun 2019 20:14:19 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 10 Jun 2019 20:14:19 +0300
Descriptions of pg_trgm GUC options have % replaced with %% like it was
a printf-like format. But that's not needed since they are just plain strings.
This commit fixed that. Backpatch to last supported version since this error
present from the beginning.
Reported-by: Masahiko Sawada
Discussion: https://postgr.es/m/CAD21AoAgPKODUsu9gqUFiNqEOAqedStxJ-a0sapsJXWWAVp%3Dxg%40mail.gmail.com
Backpatch-through: 9.4
M contrib/pg_trgm/trgm_op.c
Add docs of missing GUC to pgtrgm.sgml
commit : ba3783e0244e3502d1b08896ffc72b3a88dbdb83
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 10 Jun 2019 19:38:13 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 10 Jun 2019 19:38:13 +0300
be8a7a68 introduced pg_trgm.strict_word_similarity_threshold GUC, but missed
docs for that. This commit fixes that.
Discussion: https://postgr.es/m/fc907f70-448e-fda3-3aa4-209a59597af0%402ndquadrant.com
Author: Ian Barwick
Reviewed-by: Masahiko Sawada, Michael Paquier
Backpatch-through: 9.6
M doc/src/sgml/pgtrgm.sgml
Fix docs indentation in pgtrgm.sgml
commit : 852ddfbbe2121c905f2ecd750b1ec4cbfbea9f76
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 10 Jun 2019 19:28:47 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Mon, 10 Jun 2019 19:28:47 +0300
5871b884 introduced pg_trgm.word_similarity_threshold GUC, but its documentation
contains wrong indentation. This commit fixes that. Backpatch for easier
backpatching of other documentation fixes.
Discussion: https://postgr.es/m/4c735d30-ab59-fc0e-45d8-f90eb5ed3855%402ndquadrant.com
Author: Ian Barwick
Backpatch-through: 9.6
M doc/src/sgml/pgtrgm.sgml
MSVC: Reconcile clean.bat with PostgreSQL 12 work.
commit : ae78a9456c8986a8869ec470b40e177b5617a2f1
author : Noah Misch <noah@leadboat.com>
date : Sun, 9 Jun 2019 15:50:54 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sun, 9 Jun 2019 15:50:54 -0700
M src/tools/msvc/clean.bat
Reconcile nodes/*funcs.c with PostgreSQL 12 work.
commit : 44982e7d09cf9b1a08fded7fb0ca9a60dae869a5
author : Noah Misch <noah@leadboat.com>
date : Sun, 9 Jun 2019 14:00:36 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sun, 9 Jun 2019 14:00:36 -0700
One would have needed out-of-tree code to observe the defects. Remove
unreferenced fields instead of completing their support functions.
Since in-tree code can't reach _readIntoClause(), no catversion bump.
M src/backend/nodes/outfuncs.c
M src/backend/parser/parse_node.c
M src/include/nodes/parsenodes.h
M src/include/nodes/primnodes.h
Switch position of some declarations in libpq.h
commit : cf4263cc6c3a2310de4f1540745990e62fa2312c
author : Michael Paquier <michael@paquier.xyz>
date : Sun, 9 Jun 2019 11:33:52 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sun, 9 Jun 2019 11:33:52 +0900
This makes the header more consistent with the surroundings, with
declarations associated to a given file grouped together.
Author: Daniel Gustafsson
Discussion: https://postgr.es/m/20190608012439.GB7228@paquier.xyz
M src/include/libpq/libpq.h
Fix some typos
commit : b880e22de4b2543f1c1db758bca4b2135525e87a
author : Michael Paquier <michael@paquier.xyz>
date : Sun, 9 Jun 2019 11:25:56 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sun, 9 Jun 2019 11:25:56 +0900
Author: Guillaume Lelarge
Discussion: https://postgr.es/m/CAECtzeWPz4JikzUqZdMjqPTe8dAP3nZxPD-58Y-Hhvirg0fF+A@mail.gmail.com
M doc/src/sgml/file-fdw.sgml
M doc/src/sgml/runtime.sgml
Update documentation about SIGKILL of postmaster.
commit : a806b14a1139d3443a7c2c263abb9ff8e4a65694
author : Noah Misch <noah@leadboat.com>
date : Sat, 8 Jun 2019 10:12:26 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sat, 8 Jun 2019 10:12:26 -0700
Removing shared memory and semaphores in response to server start
failure often masks the real problem, a live process associated with the
data directory; see commit 5a907404b52753c4d6c6a7c21765aeaa42fd6a3b.
Since 9.6, it's rarely necessary to kill subprocesses manually. (When
it is necessary, that commit's HINT will say as much, in all supported
versions.)
M doc/src/sgml/runtime.sgml
Stop using spelling "nonexistant".
commit : f2c71cb71fe186dcf8ebec967f98d1c7c4777943
author : Noah Misch <noah@leadboat.com>
date : Sat, 8 Jun 2019 10:12:26 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sat, 8 Jun 2019 10:12:26 -0700
The documentation used "nonexistent" exclusively, and the source tree
used it three times as often as "nonexistant".
M contrib/test_decoding/expected/ddl.out
M contrib/test_decoding/sql/ddl.sql
M src/bin/pg_dump/t/002_pg_dump.pl
M src/interfaces/ecpg/test/connect/test1.pgc
M src/interfaces/ecpg/test/connect/test5.pgc
M src/interfaces/ecpg/test/expected/connect-test1-minGW32.stderr
M src/interfaces/ecpg/test/expected/connect-test1.c
M src/interfaces/ecpg/test/expected/connect-test1.stderr
M src/interfaces/ecpg/test/expected/connect-test5.c
M src/interfaces/ecpg/test/expected/connect-test5.stderr
M src/interfaces/ecpg/test/expected/preproc-whenever.c
M src/interfaces/ecpg/test/expected/preproc-whenever.stderr
M src/interfaces/ecpg/test/preproc/whenever.pgc
M src/test/regress/expected/alter_table.out
M src/test/regress/expected/create_am.out
M src/test/regress/expected/rowtypes.out
M src/test/regress/expected/stats_ext.out
M src/test/regress/sql/alter_table.sql
M src/test/regress/sql/create_am.sql
M src/test/regress/sql/rowtypes.sql
M src/test/regress/sql/stats_ext.sql
Update stale comments, and fix comment typos.
commit : 31d250e049b4e3d51a635edaa2221c11815e40e7
author : Noah Misch <noah@leadboat.com>
date : Sat, 8 Jun 2019 10:12:26 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sat, 8 Jun 2019 10:12:26 -0700
M src/backend/access/brin/brin_inclusion.c
M src/backend/access/transam/multixact.c
M src/backend/port/sysv_shmem.c
M src/backend/postmaster/postmaster.c
M src/backend/utils/adt/like.c
M src/bin/pg_basebackup/pg_basebackup.c
M src/bin/pg_rewind/t/RewindTest.pm
M src/bin/pg_upgrade/TESTING
M src/bin/pg_upgrade/controldata.c
M src/fe_utils/string_utils.c
M src/include/storage/s_lock.h
M src/interfaces/libpq/fe-secure-openssl.c
M src/test/recovery/t/013_crash_restart.pl
Fix assorted inconsistencies.
commit : 92c4abc73693690ce9ff13ede160f0dcb0a2de7b
author : Amit Kapila <akapila@postgresql.org>
date : Sat, 8 Jun 2019 08:16:38 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Sat, 8 Jun 2019 08:16:38 +0530
There were a number of issues in the recent commits which include typos,
code and comments mismatch, leftover function declarations. Fix them.
Reported-by: Alexander Lakhin
Author: Alexander Lakhin, Amit Kapila and Amit Langote
Reviewed-by: Amit Kapila
Discussion: https://postgr.es/m/ef0c0232-0c1d-3a35-63d4-0ebd06e31387@gmail.com
M src/backend/access/common/reloptions.c
M src/backend/access/heap/heapam.c
M src/backend/access/heap/heapam_handler.c
M src/backend/access/heap/rewriteheap.c
M src/backend/access/transam/xact.c
M src/backend/access/transam/xlog.c
M src/backend/access/transam/xloginsert.c
M src/backend/commands/copy.c
M src/backend/commands/tablecmds.c
M src/backend/executor/execTuples.c
M src/backend/executor/nodeModifyTable.c
M src/backend/lib/integerset.c
M src/backend/postmaster/postmaster.c
M src/backend/storage/smgr/md.c
M src/include/access/heapam.h
M src/include/access/tableam.h
M src/include/executor/executor.h
M src/include/storage/sync.h
M src/test/modules/test_integerset/test_integerset.c
Move be-gssapi-common.h into src/include/libpq/
commit : 35b2d4bc0eb5d61a2a294ccb6b2e4abdad307604
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 8 Jun 2019 09:59:02 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 8 Jun 2019 09:59:02 +0900
The file has been introduced in src/backend/libpq/ as of b0b39f72, but
all backend-side headers of libpq are located in src/include/libpq/.
Note that the identification path on top of the file referred to
src/include/libpq/ from the start.
Author: Michael Paquier
Reviewed-by: Stephen Frost
Discussion: https://postgr.es/m/20190607043415.GE1736@paquier.xyz
M src/backend/libpq/auth.c
M src/backend/libpq/be-gssapi-common.c
M src/backend/libpq/be-secure-gssapi.c
R100 src/backend/libpq/be-gssapi-common.h src/include/libpq/be-gssapi-common.h
Improve some comments in pg_checksums about the needed clean shutdown
commit : 84d4de97e8d14469974eb488730a13f942aa787a
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 7 Jun 2019 20:48:39 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 7 Jun 2019 20:48:39 +0900
It was not clear from the code why it is necessary. And we need a clean
shutdown to avoid random checksum failures caused by torn pages.
Author: Masahiko Sawada
Discussion: https://postgr.es/m/CAD21AoDum5MbAb7F=pa9dOD1W2tukuDMPzWT7NjZceNoWB_6Qw@mail.gmail.com
M src/bin/pg_checksums/pg_checksums.c
Fix copy-pasto in freeing memory on error in vacuumlo.
commit : 77b68e3a4f854d95350a3366ecfc8b3b506ebaa7
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 7 Jun 2019 12:42:27 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Fri, 7 Jun 2019 12:42:27 +0300
It's harmless to call PQfreemem() with a NULL argument, so the only
consequence was that if allocating 'schema' failed, but allocating 'table'
or 'field' succeeded, we would leak a bit of memory. That's highly
unlikely to happen, so this is just academical, but let's get it right.
Per bug #15838 from Timur Birsh. Backpatch back to 9.5, where the
PQfreemem() calls were introduced.
Discussion: https://www.postgresql.org/message-id/15838-3221652c72c5e69d@postgresql.org
M contrib/vacuumlo/vacuumlo.c
Fix default_tablespace usage for partitioned tables
commit : a36c84c3e4a9bee6baa740848f67a5db3fa279b0
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 7 Jun 2019 00:44:17 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 7 Jun 2019 00:44:17 -0400
In commit 87259588d0ab I (Álvaro) tried to rationalize the determination
of tablespace to use for partitioned tables, but failed to handle the
default_tablespace case. Repair and add proper tests.
Author: Amit Langote, Rushabh Lathia
Reported-by: Rushabh Lathia
Reviewed-by: Amit Langote, Álvaro Herrera
Discussion: https://postgr.es/m/CAGPqQf0cYjm1=rjxk_6gU0SjUS70=yFUAdCJLwWzh9bhNJnyVg@mail.gmail.com
M src/backend/commands/tablecmds.c
M src/test/regress/input/tablespace.source
M src/test/regress/output/tablespace.source
Fix inconsistency in comments atop ExecParallelEstimate.
commit : d8261595bc6f5189896cdce6861915ac23830e7c
author : Amit Kapila <akapila@postgresql.org>
date : Fri, 7 Jun 2019 05:23:52 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Fri, 7 Jun 2019 05:23:52 +0530
When this code was initially introduced in commit d1b7c1ff, the structure
used was SharedPlanStateInstrumentation, but later when it got changed to
Instrumentation structure in commit b287df70, we forgot to update the
comment.
Reported-by: Wu Fei
Author: Wu Fei
Reviewed-by: Amit Kapila
Backpatch-through: 9.6
Discussion: https://postgr.es/m/52E6E0843B9D774C8C73D6CF64402F0562215EB2@G08CNEXMBPEKD02.g08.fujitsu.local
M src/backend/executor/execParallel.c
Fix message style
commit : e8bdea58f960eac669ebac01dc3865606dd7b453
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 6 Jun 2019 12:18:14 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 6 Jun 2019 12:18:14 -0400
Mark one message not for translation, and prefer "cannot" over "may
not", per commentary from Robert Haas.
Discussion: https://postgr.es/m/20190430145813.GA29872@alvherre.pgsql
M src/backend/access/heap/heapam.c
M src/backend/access/table/tableamapi.c
M src/test/regress/expected/create_am.out
Add forgotten translatable string in pg_checksums.c
commit : 438e51987dcc21ca7ce28c6d1a4e58b0249eb690
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 6 Jun 2019 22:10:52 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 6 Jun 2019 22:10:52 +0900
Oversight in commit 280e5f1.
Author: Kyotaro Horiguchi
Discussion: https://postgr.es/m/20190606.200612.110313249.horikyota.ntt@gmail.com
M src/bin/pg_checksums/pg_checksums.c
pg_waldump: Fix invalid option handling
commit : f65eced25118aab29804debc4e0b9a67f4d043ad
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 5 Jun 2019 22:55:16 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 5 Jun 2019 22:55:16 +0200
Previously, running pg_waldump with an invalid option (pg_waldump
--foo) would print the help output and exit successfully. This was
because it tried to process the option letter '?' as a normal option,
but that letter is used by getopt() to report an invalid option.
To fix, process help and version options separately, like we do
everywhere else. Also add a basic test suite for pg_waldump and run
the basic option handling tests, which would have caught this.
M src/bin/pg_waldump/.gitignore
M src/bin/pg_waldump/Makefile
M src/bin/pg_waldump/pg_waldump.c
A src/bin/pg_waldump/t/001_basic.pl
Fix confusion on different kinds of slots in IndexOnlyScans.
commit : cd96389d713787b025c84869ba417c6f2f008a86
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 6 Jun 2019 09:46:52 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Thu, 6 Jun 2019 09:46:52 +0300
We used the same slot to store a tuple from the index, and to store a
tuple from the table. That's not OK. It worked with the heap, because
heapam_getnextslot() stores a HeapTuple to the slot, and doesn't care how
large the tts_values/nulls arrays are. But when I played with a toy table
AM implementation that used a virtual tuple, it caused memory overruns.
In the passing, tidy up comments on the ioss_PscanLen fields.
M src/backend/executor/nodeIndexonlyscan.c
M src/include/nodes/execnodes.h
Docs: concurrent builds of partitioned indexes are not supported
commit : 6c0c28383749c0ade89ac70ba6dbce9af140c0a9
author : David Rowley <drowley@postgresql.org>
date : Thu, 6 Jun 2019 12:36:37 +1200
committer: David Rowley <drowley@postgresql.org>
date : Thu, 6 Jun 2019 12:36:37 +1200
Document that CREATE INDEX CONCURRENTLY is not currently supported for
indexes on partitioned tables.
Discussion: https://postgr.es/m/CAKJS1f_CErd2z9L21Q8OGLD4TgH7yw1z9MAtHTSO13sXVG-yow@mail.gmail.com
Backpatch-through: 11
M doc/src/sgml/ref/create_index.sgml
doc: Add links to tables
commit : b250898c76f3a04421656f1bd8c5c520de02046d
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 5 Jun 2019 22:08:50 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 5 Jun 2019 22:08:50 +0200
Formal tables should generally have an xref in the text that points to
them. Add them here.
M doc/src/sgml/func.sgml
Fix confusing NOTICE text in REINDEX CONCURRENTLY
commit : e24a815c1c8550fcba5cc5aeb0d130db46570872
author : David Rowley <drowley@postgresql.org>
date : Wed, 5 Jun 2019 21:05:41 +1200
committer: David Rowley <drowley@postgresql.org>
date : Wed, 5 Jun 2019 21:05:41 +1200
When performing REINDEX TABLE CONCURRENTLY, if all of the table's indexes
could not be reindexed, a NOTICE message claimed that the table had no
indexes. This was confusing, so let's change the NOTICE text to something
less confusing.
In passing, also mention in the comment before ReindexRelationConcurrently
that materialized views are supported too and also explain what the return
value of the function means.
Author: Ashwin Agrawal
Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/CALfoeithHvi13p_VyR8kt9o6Pa7Z=Smi6Nfc2anHnQx5Lj8bTQ@mail.gmail.com
M src/backend/commands/indexcmds.c
M src/test/regress/expected/create_index.out
Fix incorrect index behavior in COPY FROM with partitioned tables
commit : 56b3b3838284f53c83556592e60688522155f57f
author : David Rowley <drowley@postgresql.org>
date : Wed, 5 Jun 2019 18:28:38 +1200
committer: David Rowley <drowley@postgresql.org>
date : Wed, 5 Jun 2019 18:28:38 +1200
86b85044e rewrote how COPY FROM works to allow multiple tuple buffers to
exist to once thus allowing multi-inserts to be used in more cases with
partitioned tables. That commit neglected to update the estate's
es_result_relation_info when flushing the insert buffer to the partition
making it possible for the index tuples to be added into an index on the
wrong partition.
Fix this and also add an Assert in ExecInsertIndexTuples to help ensure
that we never make this mistake again.
Reported-by: Haruka Takatsuka
Author: Ashutosh Sharma
Discussion: https://postgr.es/m/15832-b1bf336a4ee246b5@postgresql.org
M src/backend/commands/copy.c
M src/backend/executor/execIndexing.c
M src/test/regress/input/copy.source
M src/test/regress/output/copy.source
Rework code using list_delete_cell() in MergeAttributes
commit : f7e954ad1cf99a65b1785d999058898a6d56e014
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 5 Jun 2019 15:01:14 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 5 Jun 2019 15:01:14 +0900
When merging two attributes, we are sure that at least one remains.
However, when deleting one element in the attribute list we may finish
with an empty list returned as NIL by list_delete_cell(), but the code
failed to track that, which is not project-like. Adjust the call so as
we check for an empty list, and make use of it in an assertion.
This has been introduced by e7b3349, when adding support for CREATE
TABLE OF.
Author: Mark Dilger
Reviewed-by: Álvaro Herrera, Michael Paquier
Discussion: https://postgr.es/m/CAE-h2TpPDqSWgOvfvSziOaMngMPwW+QZcmPpY8hQ_KOJ2+3hXQ@mail.gmail.com
M src/backend/commands/tablecmds.c
Document piecemeal construction of partitioned indexes
commit : 5efd604ec0a3bdde98fe19d8cada69ab4ef80db3
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 4 Jun 2019 16:42:40 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 4 Jun 2019 16:42:40 -0400
Continuous operation cannot be achieved without applying this technique,
so it needs to be properly described.
Author: Álvaro Herrera
Reported-by: Tom Lane
Discussion: https://postgr.es/m/8756.1556302759@sss.pgh.pa.us
M doc/src/sgml/ddl.sgml
doc: Fix whitespace
commit : ece9dc40d6d77a8607e72931510e30cfdfb78fd4
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 4 Jun 2019 13:57:38 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 4 Jun 2019 13:57:38 +0200
Verbatim environment tags should not be indented.
M doc/src/sgml/func.sgml
Add command column to pg_stat_progress_create_index
commit : c880096dc1e14b62610aa34bc98db226fa134260
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 4 Jun 2019 09:16:02 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 4 Jun 2019 09:16:02 +0200
This allows determining which command is running, similar to
pg_stat_progress_cluster.
Discussion: https://www.postgresql.org/message-id/flat/f0e56b3b-74b7-6cbc-e207-a5ed6bee18dc%402ndquadrant.com
M doc/src/sgml/monitoring.sgml
M src/backend/catalog/index.c
M src/backend/catalog/system_views.sql
M src/backend/commands/indexcmds.c
M src/include/catalog/catversion.h
M src/include/commands/progress.h
M src/test/regress/expected/rules.out
Fix some typos and inconsistencies in tableam.h
commit : 041a2642e51eb008351435709dcb054760a43bb9
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 4 Jun 2019 09:48:25 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 4 Jun 2019 09:48:25 +0900
The defined callback definitions have been using references to heap for
a couple of variables and comments. This makes the whole interface more
consistent by using "table" which is more generic.
A variable storing index information was misspelled as well.
Author: Michael Paquier
Discussion: https://postgr.es/m/20190601190946.GB1905@paquier.xyz
M src/include/access/tableam.h
Fix contrib/auto_explain to not cause problems in parallel workers.
commit : 2cd4e835701e15f5e32dd8bde488f8669ddf7ae8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 3 Jun 2019 18:06:04 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 3 Jun 2019 18:06:04 -0400
A parallel worker process should not be making any decisions of its
own about whether to auto-explain. If the parent session process
passed down flags asking for instrumentation data, do that, otherwise
not. Trying to enable instrumentation anyway leads to bugs like the
"could not find key N in shm TOC" failure reported in bug #15821
from Christian Hofstaedtler.
We can implement this cheaply by piggybacking on the existing logic
for not doing anything when we've chosen not to sample a statement.
While at it, clean up some tin-eared coding related to the sampling
feature, including an off-by-one error that meant that asking for 1.0
sampling rate didn't actually result in sampling every statement.
Although the specific case reported here only manifested in >= v11,
I believe that related misbehaviors can be demonstrated in any version
that has parallel query; and the off-by-one error is certainly there
back to 9.6 where that feature was added. So back-patch to 9.6.
Discussion: https://postgr.es/m/15821-5eb422e980594075@postgresql.org
M contrib/auto_explain/auto_explain.c
Fix unsafe memory management in CloneRowTriggersToPartition().
commit : eaf0292c3ba7acac2735f99a8988bd49a26112f5
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 3 Jun 2019 16:59:16 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 3 Jun 2019 16:59:16 -0400
It's not really supported to call systable_getnext() in a different
memory context than systable_beginscan() was called in, and it's
*definitely* not safe to do so and then reset that context between
calls. I'm not very clear on how this code survived
CLOBBER_CACHE_ALWAYS testing ... but Alexander Lakhin found a case
that would crash it pretty reliably.
Per bug #15828. Fix, and backpatch to v11 where this code came in.
Discussion: https://postgr.es/m/15828-f6ddd7df4852f473@postgresql.org
M src/backend/commands/tablecmds.c
Update SQL conformance information about JSON path
commit : 05d36b68ed011d112ee287b1fedd981c73a48f85
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 3 Jun 2019 21:33:01 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 3 Jun 2019 21:33:01 +0200
Reviewed-by: Oleg Bartunov <obartunov@postgrespro.ru>
M src/backend/catalog/sql_features.txt
M src/include/catalog/catversion.h
Fix typos in various places
commit : 1fb6f62a84041b668fd9e85a2f33bb3a0fd28fdc
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 3 Jun 2019 13:44:03 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 3 Jun 2019 13:44:03 +0900
Author: Andrea Gelmini
Reviewed-by: Michael Paquier, Justin Pryzby
Discussion: https://postgr.es/m/20190528181718.GA39034@glet
M contrib/citext/expected/citext.out
M contrib/citext/expected/citext_1.out
M contrib/citext/sql/citext.sql
M src/backend/access/gist/gist.c
M src/backend/access/heap/heapam_handler.c
M src/backend/jit/llvm/llvmjit_inline.cpp
M src/backend/rewrite/rewriteManip.c
M src/backend/storage/buffer/buf_init.c
M src/backend/storage/ipc/standby.c
M src/backend/utils/adt/geo_ops.c
M src/backend/utils/adt/inet_net_pton.c
M src/backend/utils/adt/jsonpath.c
M src/bin/pg_basebackup/t/010_pg_basebackup.pl
M src/bin/psql/command.c
M src/common/unicode/generate-norm_test_table.pl
M src/include/executor/tuptable.h
M src/include/fe_utils/conditional.h
M src/include/nodes/execnodes.h
Fix some issues and improve psql completion for access methods
commit : 0240a00fbd4fd14f577edf8d36a032237fd0b9cb
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 3 Jun 2019 11:02:32 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 3 Jun 2019 11:02:32 +0900
The following issues have been spotted:
- CREATE INDEX .. USING suggests both index and table AMs, but it should
consider only index AMs.
- CREATE TABLE .. USING has no completion support. USING was not being
included in the completion list where it should, and follow-up
suggestions for table AMs have been missing as well.
- CREATE ACCESS METHOD .. TYPE suggests only INDEX, with TABLE missing.
Author: Michael Paquier
Discussion: https://postgr.es/m/20190601191007.GC1905@paquier.xyz
M src/bin/psql/tab-complete.c
Make cpluspluscheck more portable.
commit : f4755a2c01486519cfce5b21ab04529ad26f5ed1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 2 Jun 2019 13:45:01 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 2 Jun 2019 13:45:01 -0400
Teach it to scrape -I and -D switches from CPPFLAGS in Makefile.global.
This is useful for testing on, eg, FreeBSD, where you won't get far
without "-I/usr/local/include".
Also, expand the set of blacklisted-for-unportability atomics headers,
based on noting that arch-x86.h fails to compile on an ARM box. The
other ones I'd omitted seem to compile all right on architectures they
don't belong to, but that's surely too shaky to rely on. Let's do
like we did for the src/include/port/ headers, and ignore all except
the variant that's pulled in by the arch-independent header.
M src/tools/pginclude/cpluspluscheck
Clean up PL/Perl's handling of the _() macro.
commit : 032627ee7837f0baa539df7247e003dbaded2c90
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 2 Jun 2019 12:23:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 2 Jun 2019 12:23:39 -0400
Perl likes to redefine the _() macro:
#ifdef CAN_PROTOTYPE
#define _(args) args
#else ...
There was lots not to like about the way we dealt with this before:
1. Instead of taking care of the conflict centrally in plperl.h, we
expected every one of its ever-growing number of includers to do so.
This is duplicative and error-prone in itself, plus it means that
plperl.h fails to meet the expectation of being compilable standalone,
resulting in macro-redefinition warnings in cpluspluscheck.
2. We left _() with its Perl definition, meaning that if someone tried
to use it in any Perl-related extension, it would silently fail to
provide run-time translation. I don't see any live bugs of this ilk,
but it's clearly a hard-to-notice bug waiting to happen.
So fix that by centralizing the cleanup logic, making it match what
we're already doing for other macro conflicts with Perl. Since we only
expect plperl.h to be included by extensions not core code, we should
redefine _() as dgettext() not gettext().
M contrib/hstore_plperl/hstore_plperl.c
M contrib/jsonb_plperl/jsonb_plperl.c
M src/pl/plperl/SPI.xs
M src/pl/plperl/Util.xs
M src/pl/plperl/plperl.c
M src/pl/plperl/plperl.h
worker_spi needs a .gitignore file now.
commit : 135063e6f6ee61c7243801e9f4d702921ed53e06
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 2 Jun 2019 11:13:23 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 2 Jun 2019 11:13:23 -0400
A src/test/modules/worker_spi/.gitignore
Un-break ecpg tests for Windows.
commit : 10a53cae9993abae159abdc6a76e46f6aac120d1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 2 Jun 2019 11:07:54 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 2 Jun 2019 11:07:54 -0400
Declaring a function "inline" still doesn't work with Windows compilers
(C99? what's that?), unless the macro provided by pg_config.h is
in-scope, which it is not in our ECPG test programs. So the workaround
I tried to use in commit 7640f9312 doesn't work for Windows. Revert
the change in printf_hack.h, and instead just blacklist that file
in cpluspluscheck --- since it's a not-installed test file, we don't
really need to verify its C++ cleanliness anyway.
M src/interfaces/ecpg/test/expected/compat_informix-dec_test.c
M src/interfaces/ecpg/test/expected/pgtypeslib-num_test.c
M src/interfaces/ecpg/test/expected/pgtypeslib-num_test2.c
M src/interfaces/ecpg/test/printf_hack.h
M src/tools/pginclude/cpluspluscheck
Increase test coverage for worker_spi by ∞%
commit : 4b3f1dd71b74f82dedbf37c331d0a444368c4009
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sun, 2 Jun 2019 00:29:49 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Sun, 2 Jun 2019 00:29:49 -0400
This test module was not getting invoked, other than at compile time,
limiting its usefulness -- and keeping its coverage at 0%. Add a
minimal regression test to ensure it runs on make check-world; this
makes it 92% covered (line-wise), which seems sufficient.
Author: Álvaro Herrera <alvherre@alvh.no-ip.org>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/20190529193256.GA17603@alvherre.pgsql
M src/test/modules/worker_spi/Makefile
A src/test/modules/worker_spi/dynamic.conf
A src/test/modules/worker_spi/expected/worker_spi.out
A src/test/modules/worker_spi/sql/worker_spi.sql
M src/test/modules/worker_spi/worker_spi.c
Fix documentation of check_option in information_schema.views
commit : 0b8e0532c65c3a2d4b0e9c254efa022767bacceb
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 1 Jun 2019 15:33:47 -0400
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 1 Jun 2019 15:33:47 -0400
Support of CHECK OPTION for updatable views has been added in 9.4, but
the documentation of information_schema never got the call even if the
information displayed is correct.
Author: Gilles Darold
Discussion: https://postgr.es/m/75d07704-6c74-4f26-656a-10045c01a17e@darold.net
Backpatch-through: 9.4
M doc/src/sgml/information_schema.sgml
Improve coverage of cpluspluscheck.
commit : 6f54b80edd88abd5665aa12fbcf10f846dd80939
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 31 May 2019 16:32:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 31 May 2019 16:32:07 -0400
Formerly, cpluspluscheck was only meant to examine headers that
we thought of as exported --- but its notion of what we export
was well behind the times. Let's just make it check *all* .h
files, except for a well-defined blacklist, instead.
While at it, improve its ability to use a C++ compiler other than g++,
by scraping the CXX setting from Makefile.global and making it possible
to override the warning options used (per suggestion from Andres Freund).
Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru
M src/tools/pginclude/cpluspluscheck
Integrate cpluspluscheck into build system.
commit : b1cd7ce23f40e1e443b3f2ab127bbe8348add678
author : Andres Freund <andres@anarazel.de>
date : Fri, 31 May 2019 12:36:17 -0700
committer: Andres Freund <andres@anarazel.de>
date : Fri, 31 May 2019 12:36:17 -0700
Previously cpluspluscheck wouldn't work in vpath builds, this commit
fixes that. To make it easier to invoke, there's a top-level
cpluspluscheck target.
Discussion: https://postgr.es/20190530220244.kiputcbl4gkl2oo6@alap3.anarazel.de
M GNUmakefile.in
M src/tools/pginclude/cpluspluscheck
Fix incorrect parameter name in comment
commit : 72b6223f766d6ba9076d7b1ebdf05df75e83ba5c
author : David Rowley <drowley@postgresql.org>
date : Fri, 31 May 2019 13:30:05 -0400
committer: David Rowley <drowley@postgresql.org>
date : Fri, 31 May 2019 13:30:05 -0400
Author: Antonin Houska
Discussion: https://postgr.es/m/22370.1559293357@localhost
M src/include/access/tableam.h
Adjust ecpg expected-results files for commit 7640f9312.
commit : ec66ec8b21d3d779047313ac214fba7bcd29a97c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 31 May 2019 12:47:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 31 May 2019 12:47:19 -0400
Mea culpa for not rechecking check-world at the last step :-(
Per buildfarm.
M src/interfaces/ecpg/test/expected/compat_informix-dec_test.c
M src/interfaces/ecpg/test/expected/pgtypeslib-num_test.c
M src/interfaces/ecpg/test/expected/pgtypeslib-num_test2.c
Fix C++ incompatibilities in ecpg/preproc/ header files.
commit : 4f67858d3f210658d42f44fc674d2850581e572e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 31 May 2019 12:38:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 31 May 2019 12:38:53 -0400
There's probably no need to back-patch this, since it seems unlikely
that anybody would be inserting C++ code into ecpg's preprocessor.
Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru
M src/interfaces/ecpg/preproc/ecpg.c
M src/interfaces/ecpg/preproc/pgc.l
M src/interfaces/ecpg/preproc/type.h
Fix C++ incompatibilities in plpgsql's header files.
commit : 3f61b3205f1a8bd27909be97341f002db8842093
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 31 May 2019 12:34:54 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 31 May 2019 12:34:54 -0400
Rename some exposed parameters so that they don't conflict with
C++ reserved words.
Back-patch to all supported versions.
George Tarasov
Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru
M src/pl/plpgsql/src/pl_comp.c
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpgsql/src/plpgsql.h
Fix assorted header files that failed to compile standalone.
commit : 7640f9312321ceba2af61f7017da7e64f0f7b667
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 31 May 2019 11:45:33 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 31 May 2019 11:45:33 -0400
We have a longstanding project convention that all .h files should
be includable with no prerequisites other than postgres.h. This is
tested/relied-on by cpluspluscheck. However, cpluspluscheck has not
historically been applied to most headers outside the src/include
tree, with the predictable consequence that some of them don't work.
Fix that, usually by adding missing #include dependencies.
The change in printf_hack.h might require some explanation: without
it, my C++ compiler whines that the function is unused. There's
not so many call sites that "inline" is going to cost much, and
besides all the callers are in test code that we really don't care
about the size of.
There's no actual bugs being fixed here, so I see no need to back-patch.
Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru
M src/bin/pg_waldump/rmgrdesc.h
M src/bin/psql/crosstabview.h
M src/interfaces/ecpg/ecpglib/ecpglib_extern.h
M src/interfaces/ecpg/test/printf_hack.h
M src/interfaces/libpq/fe-gssapi-common.h
M src/pl/plperl/plperl_helpers.h
M src/pl/plpython/plpy_elog.h
M src/pl/plpython/plpy_resultobject.h
M src/pl/plpython/plpy_spi.h
M src/pl/plpython/plpy_subxactobject.h
M src/pl/plpython/plpy_typeio.h
M src/pl/plpython/plpy_util.h
M src/pl/plpython/plpython.h
Make our perfect hash functions be valid C++.
commit : 9e58705a7f9728f10b2e0f0c9adc6e6ecff7486e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 31 May 2019 10:40:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 31 May 2019 10:40:00 -0400
While C is happy to cast "const void *" to "const unsigned char *"
silently, C++ insists on an explicit cast. Since we put these
functions into header files, cpluspluscheck whines about that.
Add the cast to pacify it.
Discussion: https://postgr.es/m/b517ec3918d645eb950505eac8dd434e@gaz-is.ru
M src/tools/PerfectHash.pm
Fix double-phrase typo in message
commit : d22f885f895add7e0184b08a78ba92ff091e36c4
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 31 May 2019 10:08:37 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Fri, 31 May 2019 10:08:37 -0400
New in 147e3722f7e5.
M src/backend/access/table/tableam.c
Rework options of pg_checksums options for filenode handling
commit : fc115d0f9fc656967260815c031e0f25741428ae
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 30 May 2019 16:58:17 -0400
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 30 May 2019 16:58:17 -0400
This makes the tool consistent with the option set of oid2name, which
has been historically using -f for filenodes, and has more recently
gained long options and --filenode via 1aaf532.
Reported-by: Peter Eisentraut
Author: Fabien Coelho
Discussion: https://postgr.es/m/97045260-fb9e-e145-a950-cf7d28c4eaea@2ndquadrant.com
M doc/src/sgml/ref/pg_checksums.sgml
M src/bin/pg_checksums/pg_checksums.c
M src/bin/pg_checksums/t/002_actions.pl
Remove unnecessary (and wrong) forward declaration.
commit : 13002bf0bcdf4900987684ca6ef7665a25aa692b
author : Andres Freund <andres@anarazel.de>
date : Thu, 30 May 2019 13:44:38 -0700
committer: Andres Freund <andres@anarazel.de>
date : Thu, 30 May 2019 13:44:38 -0700
Interestingly only C++ compilers have, so far, complained about this
odd forward declaration. This originated when IndexBuildCallback was
defined in another file, but now is completely unnecessary (but was
wrong before too, cpluspluscheck just wouldn't have noticed).
Reported-By: Tom Lane
Discussion: https://postgr.es/m/53941.1559239260@sss.pgh.pa.us
M src/include/access/tableam.h
Make error logging in extended statistics more consistent
commit : fe415ff10408a1487d5773b47459306476ec58f0
author : Tomas Vondra <tomas.vondra@postgresql.org>
date : Thu, 30 May 2019 16:16:12 +0200
committer: Tomas Vondra <tomas.vondra@postgresql.org>
date : Thu, 30 May 2019 16:16:12 +0200
Most errors reported in extended statistics are internal issues, and so
should use elog(). The MCV list code was already following this rule, but
the functional dependencies and ndistinct coefficients were using a mix
of elog() and ereport(). Fix this by changing most places to elog(), with
the exception of input functions.
This is a mostly cosmetic change, it makes the life a little bit easier
for translators, as elog() messages are not translated. So backpatch to
PostgreSQL 10, where extended statistics were introduced.
Author: Tomas Vondra
Backpatch-through: 10 where extended statistics were added
Discussion: https://postgr.es/m/20190503154404.GA7478@alvherre.pgsql
M src/backend/statistics/dependencies.c
M src/backend/statistics/mvdistinct.c
Fix some documentation about access methods
commit : 56b78626c7288fad498c0fae7fe4fd1f240ed13f
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 29 May 2019 11:37:37 -0400
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 29 May 2019 11:37:37 -0400
Author: Guillaume Lelarge
Discussion: https://postgr.es/m/CAECtzeWPz4JikzUqZdMjqPTe8dAP3nZxPD-58Y-Hhvirg0fF+A@mail.gmail.com
M doc/src/sgml/catalogs.sgml
M doc/src/sgml/tablesample-method.sgml
Fix some documentation about FKs and partitioned tables
commit : f73293aba4d43e48707e361b2b1ef1465fef46e0
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 29 May 2019 11:19:06 -0400
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 29 May 2019 11:19:06 -0400
This got forgotten in f56f8f which has added foreign key support for
partitioned tables. In passing, add a mention about caveats applying to
tables partitioned using inheritance regarding indexes and foreign keys.
Author: Paul A Jungwirth
Reviewed-by: Amit Langote, Michael Paquier
Discussion: https://postgr.es/m/CA+renyUuSmYgmZjKc_DfUNVZ0uttF91-FwhDVW3F7WEPj0jL5w@mail.gmail.com
M doc/src/sgml/ddl.sgml
Make one message just like all its siblings.
commit : d890fa812dd4620db0d092da1cd7cba01494cd21
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 28 May 2019 23:44:22 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 28 May 2019 23:44:22 -0400
M src/backend/storage/page/bufpage.c
Fix typo in message
commit : a100974751baec7e13a527bf0c378ce8ef2787b6
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 28 May 2019 17:34:38 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 28 May 2019 17:34:38 -0400
I introduced the typo in source code in the course of 75445c1515ff.
Repair.
M src/backend/commands/subscriptioncmds.c
M src/test/regress/expected/subscription.out
In the pg_upgrade test suite, don't write to src/test/regress.
commit : 40b132c1afbb4b1494aa8e48cc35ec98d2b90777
author : Noah Misch <noah@leadboat.com>
date : Tue, 28 May 2019 12:59:00 -0700
committer: Noah Misch <noah@leadboat.com>
date : Tue, 28 May 2019 12:59:00 -0700
When this suite runs installcheck, redirect file creations from
src/test/regress to src/bin/pg_upgrade/tmp_check/regress. This closes a
race condition in "make -j check-world". If the pg_upgrade suite wrote
to a given src/test/regress/results file in parallel with the regular
src/test/regress invocation writing it, a test failed spuriously. Even
without parallelism, in "make -k check-world", the suite finishing
second overwrote the other's regression.diffs. This revealed test
"largeobject" assuming @abs_builddir@ is getcwd(), so fix that, too.
Buildfarm client REL_10, released fifty-four days ago, supports saving
regression.diffs from its new location. When an older client reports a
pg_upgradeCheck failure, it will no longer include regression.diffs.
Back-patch to 9.5, where pg_upgrade moved to src/bin.
Reviewed (in earlier versions) by Andrew Dunstan.
Discussion: https://postgr.es/m/20181224034411.GA3224776@rfd.leadboat.com
M src/bin/pg_upgrade/test.sh
M src/test/regress/input/largeobject.source
M src/test/regress/output/largeobject.source
M src/test/regress/output/largeobject_1.source
M src/tools/msvc/vcregress.pl
In the pg_upgrade test suite, remove and recreate "tmp_check".
commit : 10b72deafea5972edcafb9eb3f97154f32ccd340
author : Noah Misch <noah@leadboat.com>
date : Tue, 28 May 2019 12:58:30 -0700
committer: Noah Misch <noah@leadboat.com>
date : Tue, 28 May 2019 12:58:30 -0700
This allows "vcregress upgradecheck" to pass twice in immediate
succession, and it's more like how $(prove_check) works. Back-patch to
9.5, where pg_upgrade moved to src/bin.
Discussion: https://postgr.es/m/20190520012436.GA1480421@rfd.leadboat.com
M src/bin/pg_upgrade/test.sh
M src/tools/msvc/vcregress.pl
v12 release notes: Correct contributor name.
commit : d5ec46bf224d2ea1b010b2bc10a65e44d4456553
author : Andres Freund <andres@anarazel.de>
date : Tue, 28 May 2019 09:06:40 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 28 May 2019 09:06:40 -0700
Mea culpa.
M doc/src/sgml/release-12.sgml
Fix comment
commit : a94fd139df975a006d1697d2a7180d3656222d4d
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 28 May 2019 08:26:24 -0400
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 28 May 2019 08:26:24 -0400
This code block was copied/adapted from other similar places but
somehow the comment placement was changed so that it makes less sense.
M src/bin/pg_checksums/pg_checksums.c
docs: PG 12 relnote wording fix
commit : 3ceaed106d95e76c7dbfd41f5d83a163fd0d25c8
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 28 May 2019 07:17:34 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 28 May 2019 07:17:34 -0400
Reported-by: Gaby Schilders
M doc/src/sgml/release-12.sgml
Fix typos in SQL scripts of pgcrypto
commit : af94ea7406f332567331a9b2525fae4b57c96061
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 28 May 2019 06:33:30 -0400
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 28 May 2019 06:33:30 -0400
Author: Gurjeet Singh
Discussion: https://postgr.es/m/CABwTF4U_5kEnH93PXZEuEsZHuoSSuBEOqC6pian8vDfLZSQJNA@mail.gmail.com
M contrib/pgcrypto/expected/hmac-sha1.out
M contrib/pgcrypto/expected/pgp-decrypt.out
M contrib/pgcrypto/sql/hmac-sha1.sql
M contrib/pgcrypto/sql/pgp-decrypt.sql
doc: Fix generated column documentation
commit : 00ef6e3b28a8220f2dba881dbf56e3ba62f851bd
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 27 May 2019 12:26:16 -0400
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 27 May 2019 12:26:16 -0400
The old text still had an implicit reference to the virtual behavior,
which was not in the final patch.
Author: Tobias Bussmann <t.bussmann@gmx.net>
M doc/src/sgml/ref/create_foreign_table.sgml
M doc/src/sgml/ref/create_table.sgml
Fix more thinkos in new ECPG "PREPARE AS" code.
commit : 39fe881d3cf315d8d2ea9ee4ea1e3e39a82d5cc7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 26 May 2019 10:39:11 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 26 May 2019 10:39:11 -0400
ecpg_build_params() failed to check for ecpg_alloc failure in one
newly-added code path, and leaked a temporary string in another path.
Errors in commit a1dc6ab46, spotted by Coverity.
M src/interfaces/ecpg/ecpglib/execute.c
Fix thinko in new ECPG "PREPARE AS" code.
commit : 331695a4d9ca40864240aca721dc588a206ff395
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 26 May 2019 10:06:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 26 May 2019 10:06:37 -0400
ecpg_register_prepared_stmt() is pretty obviously checking the wrong
variable while trying to detect malloc failure. Error in commit
a1dc6ab46, spotted by Coverity.
M src/interfaces/ecpg/ecpglib/prepare.c
Fix typos.
commit : 9679345f3c5ec071f63db358581e28f06c8744a7
author : Amit Kapila <akapila@postgresql.org>
date : Sun, 26 May 2019 18:28:18 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Sun, 26 May 2019 18:28:18 +0530
Reported-by: Alexander Lakhin
Author: Alexander Lakhin
Reviewed-by: Amit Kapila and Tom Lane
Discussion: https://postgr.es/m/7208de98-add8-8537-91c0-f8b089e2928c@gmail.com
M contrib/postgres_fdw/postgres_fdw.c
M doc/src/sgml/charset.sgml
M doc/src/sgml/monitoring.sgml
M doc/src/sgml/storage.sgml
M src/backend/access/nbtree/nbtinsert.c
M src/backend/access/nbtree/nbtutils.c
M src/backend/commands/copy.c
M src/backend/commands/tablecmds.c
M src/backend/executor/execMain.c
M src/backend/executor/execTuples.c
M src/backend/jit/llvm/llvmjit_deform.c
M src/backend/libpq/hba.c
M src/backend/postmaster/syslogger.c
M src/backend/statistics/mcv.c
M src/backend/utils/adt/float.c
M src/backend/utils/adt/jsonpath_scan.l
M src/backend/utils/misc/guc.c
M src/bin/pg_dump/t/002_pg_dump.pl
M src/include/statistics/statistics.h
M src/include/utils/jsonpath.h
M src/interfaces/libpq/pqexpbuffer.c
Change Graphviz file extension
commit : 41205719d34969018f708baa70d9d06dae0c0d08
author : Peter Eisentraut <peter@eisentraut.org>
date : Sun, 26 May 2019 08:08:05 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Sun, 26 May 2019 08:08:05 +0200
Change extension for Graphviz files from .dot to .gv. The latter
appears to be the generally preferred one nowadays.
Discussion: https://www.postgresql.org/message-id/flat/71fe76d2-c7d7-2acc-6762-bbf9e61c566e%402ndquadrant.com
M contrib/pg_trgm/trgm_regexp.c
M doc/src/sgml/images/Makefile
R100 doc/src/sgml/images/gin.dot doc/src/sgml/images/gin.gv
Doc: fix incorrect references in PG 12 release notes.
commit : 02aa15de1b3821b0288a13dec71ce99f2e31fda5
author : Amit Kapila <akapila@postgresql.org>
date : Sat, 25 May 2019 15:40:53 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Sat, 25 May 2019 15:40:53 +0530
Reported-by: Euler Taveira
Author: Euler Taveira
Discussion: https://postgr.es/m/CAHE3wgjiA8DdnUzH9WqBLxdrUVvjDkKNdHx-MkEg9uV+HtpMfg@mail.gmail.com
M doc/src/sgml/release-12.sgml
Doc: fix typo in pgbench random_zipfian() documentation.
commit : 591fb289c3eef010ee1bb271a54fab7da385c4cd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 24 May 2019 11:16:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 24 May 2019 11:16:06 -0400
Per bug #15819 from Koizumi Satoru.
Discussion: https://postgr.es/m/15819-e6191bef1f7334c0@postgresql.org
M doc/src/sgml/ref/pgbench.sgml
Update copyright year.
commit : 4c9210f34c621639f896d57cf7bfb5e9be139c91
author : Thomas Munro <tmunro@postgresql.org>
date : Thu, 23 May 2019 13:23:59 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Thu, 23 May 2019 13:23:59 +1200
Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/CA%2BhUKGJFWXmtYo6Frd77RR8YXCHz7hJ2mRy5aHV%3D7fJOqDnBHA%40mail.gmail.com
M src/backend/lib/integerset.c
M src/backend/libpq/be-gssapi-common.c
M src/backend/libpq/be-gssapi-common.h
M src/backend/libpq/be-secure-gssapi.c
M src/interfaces/libpq/fe-gssapi-common.c
M src/interfaces/libpq/fe-gssapi-common.h
M src/interfaces/libpq/fe-secure-gssapi.c
Fix typos.
commit : 7988cb446d20512ec9d091db66dba6adee3f3d4b
author : Thomas Munro <tmunro@postgresql.org>
date : Thu, 23 May 2019 13:17:41 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Thu, 23 May 2019 13:17:41 +1200
Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/CA%2BhUKGJFWXmtYo6Frd77RR8YXCHz7hJ2mRy5aHV%3D7fJOqDnBHA%40mail.gmail.com
M src/backend/executor/execTuples.c
M src/backend/replication/logical/reorderbuffer.c
M src/backend/storage/file/sharedfileset.c
M src/bin/pg_dump/pg_backup.h
M src/bin/pg_dump/pg_backup_archiver.h
M src/bin/pg_dump/pg_backup_directory.c
M src/bin/pg_dump/pg_backup_null.c
M src/bin/pg_dump/pg_backup_tar.c
tableam: Rename wrapper functions to match callback names.
commit : 73b8c3bd2889fed986044e15aefd0911f96ccdd3
author : Andres Freund <andres@anarazel.de>
date : Thu, 23 May 2019 16:25:48 -0700
committer: Andres Freund <andres@anarazel.de>
date : Thu, 23 May 2019 16:25:48 -0700
Some of the wrapper functions didn't match the callback names. Many of
them due to staying "consistent" with historic naming of the wrapped
functionality. We decided that for most cases it's more important to
be for tableam to be consistent going forward, than with the past.
The one exception is beginscan/endscan/... because it'd have looked
odd to have systable_beginscan/endscan/... with a different naming
scheme, and changing the systable_* APIs would have caused way too
much churn (including breaking a lot of external users).
Author: Ashwin Agrawal, with some small additions by Andres Freund
Reviewed-By: Andres Freund
Discussion: https://postgr.es/m/CALfoeiugyrXZfX7n0ORCa4L-m834dzmaE8eFdbNR6PMpetU4Ww@mail.gmail.com
M src/backend/access/heap/heapam.c
M src/backend/access/table/tableam.c
M src/backend/commands/copy.c
M src/backend/commands/createas.c
M src/backend/commands/matview.c
M src/backend/commands/tablecmds.c
M src/backend/commands/trigger.c
M src/backend/executor/execMain.c
M src/backend/executor/execReplication.c
M src/backend/executor/nodeLockRows.c
M src/backend/executor/nodeModifyTable.c
M src/backend/executor/nodeTidscan.c
M src/backend/utils/adt/tid.c
M src/include/access/tableam.h
Fix table dump in pg_dump[all] with backends older than 9.5
commit : 54487d1560619a0027e0651d1b8d715ca8fc388c
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 24 May 2019 08:19:21 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 24 May 2019 08:19:21 +0900
The access method name "amname" can be dumped as of 3b925e90, but
queries for backends older than 9.5 forgot to map it to a dummy NULL
value, causing the column to not be mapped to a number. As a result,
pg_dump was throwing some spurious errors in its stderr output coming
from libpq:
pg_dump: column number -1 is out of range 0..36
Fix this issue by adding a mapping of "amname" to NULL to all the older
queries.
Discussion: https://postgr.es/m/20190522083038.GA16837@paquier.xyz
Author: Michael Paquier
Reviewed-by: Dmitry Dolgov, Andres Freund, Tom Lane
M src/bin/pg_dump/pg_dump.c
pg_upgrade: Make test.sh's installcheck use to-be-upgraded version's bindir.
commit : f916221df5652b95c402847905bdf48950b5b281
author : Andres Freund <andres@anarazel.de>
date : Thu, 23 May 2019 14:46:52 -0700
committer: Andres Freund <andres@anarazel.de>
date : Thu, 23 May 2019 14:46:52 -0700
On master (after 700538) the old version's installed psql was used -
even when the old version might not actually be installed / might be
installed into a temporary directory. As commonly the case when just
executing make check for pg_upgrade, as $oldbindir is just the current
version's $bindir.
In the back branches, with --install specified, psql from the new
version's temporary installation was used, without --install (e.g for
NO_TEMP_INSTALL, cf 47b3c26642), the new version's installed psql was
used (which might or might not exist).
Author: Andres Freund
Discussion: https://postgr.es/m/20190522175150.c26f4jkqytahajdg@alap3.anarazel.de
M src/bin/pg_upgrade/test.sh
Fix array size allocation for HashAggregate hash keys.
commit : 44e95b5728a4569c494fa4ea4317f8a2f50a206b
author : Andrew Gierth <rhodiumtoad@postgresql.org>
date : Thu, 23 May 2019 15:26:01 +0100
committer: Andrew Gierth <rhodiumtoad@postgresql.org>
date : Thu, 23 May 2019 15:26:01 +0100
When there were duplicate columns in the hash key list, the array
sizes could be miscomputed, resulting in access off the end of the
array. Adjust the computation to ensure the array is always large
enough.
(I considered whether the duplicates could be removed in planning, but
I can't rule out the possibility that duplicate columns might have
different hash functions assigned. Simpler to just make sure it works
at execution time regardless.)
Bug apparently introduced in fc4b3dea2 as part of narrowing down the
tuples stored in the hashtable. Reported by Colm McHugh of Salesforce,
though I didn't use their patch. Backpatch back to version 10 where
the bug was introduced.
Discussion: https://postgr.es/m/CAFeeJoKKu0u+A_A9R9316djW-YW3-+Gtgvy3ju655qRHR3jtdA@mail.gmail.com
M src/backend/executor/nodeAgg.c
M src/test/regress/expected/aggregates.out
M src/test/regress/sql/aggregates.sql
Fix ordering of GRANT commands in pg_dumpall for tablespaces
commit : 156c0c2dff403fd115f3a5f6d73ab80959c84129
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 23 May 2019 10:48:17 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 23 May 2019 10:48:17 +0900
This uses a method similar to 68a7c24f and now b8c6014 (applied for
database creation), which guarantees that GRANT commands using the WITH
GRANT OPTION are dumped in a way so as cascading dependencies are
respected. Note that tablespaces do not have support for initial
privileges via pg_init_privs, so the same method needs to be applied
again. It would be nice to merge all the logic generating ACL queries
in dumps under the same banner, but this requires extending the support
of pg_init_privs to objects that cannot use it yet, so this is left as
future work.
Discussion: https://postgr.es/m/20190522071555.GB1278@paquier.xyz
Author: Michael Paquier
Reviewed-by: Nathan Bossart
Backpatch-through: 9.6
M src/bin/pg_dump/pg_dumpall.c
Remove -o/--oids from pg_dumpall
commit : 657c2384c6c79c6ed0d6f71f811b2fc7c41f104a
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 23 May 2019 09:36:28 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 23 May 2019 09:36:28 +0900
This has been forgotten in 578b229, which has removed support for WITH
OIDS.
Discussion: https://postgr.es/m/CALAY4q99FcFCoG6ddke0V-AksGe82L_+bhDWgEfgZBakB840zA@mail.gmail.com
Author: Surafel Temesgen
M doc/src/sgml/ref/pg_dumpall.sgml
M src/bin/pg_dump/pg_dumpall.c
Initial pgperltidy run for v12.
commit : db6e2b4c52ade524f3db419d75084728e96e1f9c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 13:36:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 13:36:19 -0400
Make all the perl code look nice, too (for some value of "nice").
M src/backend/catalog/genbki.pl
M src/backend/utils/Gen_fmgrtab.pl
M src/bin/initdb/t/001_initdb.pl
M src/bin/pg_basebackup/t/010_pg_basebackup.pl
M src/bin/pg_checksums/t/002_actions.pl
M src/bin/pg_ctl/t/001_start_stop.pl
M src/bin/pg_ctl/t/004_logrotate.pl
M src/bin/pg_dump/t/001_basic.pl
M src/bin/pg_dump/t/002_pg_dump.pl
M src/bin/pg_rewind/t/002_databases.pl
M src/bin/pg_rewind/t/RewindTest.pm
M src/bin/pgbench/t/001_pgbench_with_server.pl
M src/bin/scripts/t/090_reindexdb.pl
M src/bin/scripts/t/100_vacuumdb.pl
M src/include/catalog/unused_oids
M src/interfaces/ecpg/preproc/check_rules.pl
M src/interfaces/ecpg/preproc/parse.pl
M src/test/modules/commit_ts/t/004_restart.pl
M src/test/perl/TestLib.pm
M src/test/recovery/t/001_stream_rep.pl
M src/test/recovery/t/003_recovery_targets.pl
M src/test/recovery/t/004_timeline_switch.pl
M src/test/recovery/t/013_crash_restart.pl
M src/test/recovery/t/015_promotion_pages.pl
M src/test/recovery/t/016_min_consistency.pl
M src/test/ssl/t/001_ssltests.pl
M src/test/ssl/t/002_scram.pl
M src/test/subscription/t/002_types.pl
M src/test/subscription/t/011_generated.pl
M src/test/subscription/t/012_collation.pl
M src/test/subscription/t/100_bugs.pl
M src/tools/gen_keywordlist.pl
M src/tools/msvc/Install.pm
M src/tools/msvc/Solution.pm
M src/tools/msvc/build.pl
M src/tools/msvc/install.pl
M src/tools/msvc/mkvcbuild.pl
M src/tools/msvc/vcregress.pl
Phase 2 pgindent run for v12.
commit : 8255c7a5eeba8f1a38b7a431c04909bde4f5e67d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 13:04:48 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 13:04:48 -0400
Switch to 2.1 version of pg_bsd_indent. This formats
multiline function declarations "correctly", that is with
additional lines of parameter declarations indented to match
where the first line's left parenthesis is.
Discussion: https://postgr.es/m/CAEepm=0P3FeTXRcU5B2W3jv3PgRVZ-kGUXLGfd42FFhUROO3ug@mail.gmail.com
M contrib/amcheck/verify_nbtree.c
M contrib/auto_explain/auto_explain.c
M contrib/bloom/bloom.h
M contrib/btree_gist/btree_utils_num.h
M contrib/btree_gist/btree_utils_var.h
M contrib/dblink/dblink.c
M contrib/file_fdw/file_fdw.c
M contrib/intarray/_int_selfuncs.c
M contrib/jsonb_plpython/jsonb_plpython.c
M contrib/ltree/lquery_op.c
M contrib/ltree/ltree.h
M contrib/pageinspect/brinfuncs.c
M contrib/pageinspect/rawpage.c
M contrib/pg_stat_statements/pg_stat_statements.c
M contrib/pg_trgm/trgm.h
M contrib/pg_trgm/trgm_regexp.c
M contrib/pg_visibility/pg_visibility.c
M contrib/pgcrypto/imath.c
M contrib/pgcrypto/mbuf.h
M contrib/pgcrypto/pgp-decrypt.c
M contrib/pgcrypto/pgp.h
M contrib/pgcrypto/px-crypt.h
M contrib/pgstattuple/pgstattuple.c
M contrib/postgres_fdw/connection.c
M contrib/postgres_fdw/deparse.c
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/postgres_fdw.h
M contrib/sepgsql/sepgsql.h
M contrib/tablefunc/tablefunc.c
M contrib/test_decoding/test_decoding.c
M contrib/tsm_system_rows/tsm_system_rows.c
M contrib/tsm_system_time/tsm_system_time.c
M contrib/xml2/xpath.c
M src/backend/access/brin/brin.c
M src/backend/access/brin/brin_inclusion.c
M src/backend/access/brin/brin_minmax.c
M src/backend/access/brin/brin_pageops.c
M src/backend/access/brin/brin_revmap.c
M src/backend/access/brin/brin_tuple.c
M src/backend/access/common/printtup.c
M src/backend/access/common/reloptions.c
M src/backend/access/gin/ginbtree.c
M src/backend/access/gin/gindatapage.c
M src/backend/access/gin/ginentrypage.c
M src/backend/access/gist/gist.c
M src/backend/access/gist/gistbuild.c
M src/backend/access/gist/gistbuildbuffers.c
M src/backend/access/gist/gistproc.c
M src/backend/access/gist/gistvacuum.c
M src/backend/access/hash/hash.c
M src/backend/access/hash/hashinsert.c
M src/backend/access/hash/hashpage.c
M src/backend/access/hash/hashsearch.c
M src/backend/access/heap/heapam.c
M src/backend/access/heap/heapam_handler.c
M src/backend/access/heap/pruneheap.c
M src/backend/access/heap/syncscan.c
M src/backend/access/heap/tuptoaster.c
M src/backend/access/heap/vacuumlazy.c
M src/backend/access/index/indexam.c
M src/backend/access/nbtree/nbtinsert.c
M src/backend/access/nbtree/nbtpage.c
M src/backend/access/nbtree/nbtree.c
M src/backend/access/nbtree/nbtsearch.c
M src/backend/access/nbtree/nbtsort.c
M src/backend/access/nbtree/nbtsplitloc.c
M src/backend/access/nbtree/nbtutils.c
M src/backend/access/tablesample/bernoulli.c
M src/backend/access/tablesample/system.c
M src/backend/access/transam/clog.c
M src/backend/access/transam/commit_ts.c
M src/backend/access/transam/generic_xlog.c
M src/backend/access/transam/multixact.c
M src/backend/access/transam/slru.c
M src/backend/access/transam/twophase.c
M src/backend/access/transam/xact.c
M src/backend/access/transam/xlog.c
M src/backend/access/transam/xloginsert.c
M src/backend/access/transam/xlogreader.c
M src/backend/catalog/aclchk.c
M src/backend/catalog/dependency.c
M src/backend/catalog/heap.c
M src/backend/catalog/index.c
M src/backend/catalog/namespace.c
M src/backend/catalog/objectaddress.c
M src/backend/catalog/partition.c
M src/backend/catalog/pg_aggregate.c
M src/backend/catalog/pg_operator.c
M src/backend/catalog/pg_proc.c
M src/backend/catalog/pg_shdepend.c
M src/backend/catalog/toasting.c
M src/backend/commands/analyze.c
M src/backend/commands/async.c
M src/backend/commands/cluster.c
M src/backend/commands/copy.c
M src/backend/commands/dbcommands.c
M src/backend/commands/dropcmds.c
M src/backend/commands/event_trigger.c
M src/backend/commands/explain.c
M src/backend/commands/extension.c
M src/backend/commands/indexcmds.c
M src/backend/commands/lockcmds.c
M src/backend/commands/matview.c
M src/backend/commands/opclasscmds.c
M src/backend/commands/policy.c
M src/backend/commands/prepare.c
M src/backend/commands/proclang.c
M src/backend/commands/publicationcmds.c
M src/backend/commands/sequence.c
M src/backend/commands/statscmds.c
M src/backend/commands/tablecmds.c
M src/backend/commands/tablespace.c
M src/backend/commands/trigger.c
M src/backend/commands/tsearchcmds.c
M src/backend/commands/typecmds.c
M src/backend/commands/user.c
M src/backend/commands/vacuum.c
M src/backend/executor/execCurrent.c
M src/backend/executor/execExpr.c
M src/backend/executor/execExprInterp.c
M src/backend/executor/execIndexing.c
M src/backend/executor/execMain.c
M src/backend/executor/execParallel.c
M src/backend/executor/execPartition.c
M src/backend/executor/execSRF.c
M src/backend/executor/execTuples.c
M src/backend/executor/functions.c
M src/backend/executor/instrument.c
M src/backend/executor/nodeAgg.c
M src/backend/executor/nodeBitmapHeapscan.c
M src/backend/executor/nodeGatherMerge.c
M src/backend/executor/nodeHash.c
M src/backend/executor/nodeHashjoin.c
M src/backend/executor/nodeIndexonlyscan.c
M src/backend/executor/nodeIndexscan.c
M src/backend/executor/nodeModifyTable.c
M src/backend/executor/nodeSubplan.c
M src/backend/executor/nodeWindowAgg.c
M src/backend/executor/spi.c
M src/backend/jit/llvm/llvmjit_expr.c
M src/backend/lib/bloomfilter.c
M src/backend/lib/dshash.c
M src/backend/lib/integerset.c
M src/backend/lib/pairingheap.c
M src/backend/libpq/auth-scram.c
M src/backend/libpq/auth.c
M src/backend/libpq/be-gssapi-common.h
M src/backend/libpq/be-secure-openssl.c
M src/backend/libpq/hba.c
M src/backend/libpq/ifaddr.c
M src/backend/nodes/nodeFuncs.c
M src/backend/nodes/tidbitmap.c
M src/backend/optimizer/geqo/geqo_eval.c
M src/backend/optimizer/path/allpaths.c
M src/backend/optimizer/path/clausesel.c
M src/backend/optimizer/path/costsize.c
M src/backend/optimizer/path/equivclass.c
M src/backend/optimizer/path/indxpath.c
M src/backend/optimizer/path/joinpath.c
M src/backend/optimizer/path/joinrels.c
M src/backend/optimizer/path/pathkeys.c
M src/backend/optimizer/plan/analyzejoins.c
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/plan/initsplan.c
M src/backend/optimizer/plan/planagg.c
M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/plan/setrefs.c
M src/backend/optimizer/plan/subselect.c
M src/backend/optimizer/prep/prepjointree.c
M src/backend/optimizer/prep/preptlist.c
M src/backend/optimizer/prep/prepunion.c
M src/backend/optimizer/util/appendinfo.c
M src/backend/optimizer/util/clauses.c
M src/backend/optimizer/util/inherit.c
M src/backend/optimizer/util/orclauses.c
M src/backend/optimizer/util/pathnode.c
M src/backend/optimizer/util/plancat.c
M src/backend/optimizer/util/predtest.c
M src/backend/optimizer/util/relnode.c
M src/backend/optimizer/util/restrictinfo.c
M src/backend/optimizer/util/tlist.c
M src/backend/optimizer/util/var.c
M src/backend/parser/analyze.c
M src/backend/parser/parse_agg.c
M src/backend/parser/parse_clause.c
M src/backend/parser/parse_coerce.c
M src/backend/parser/parse_collate.c
M src/backend/parser/parse_expr.c
M src/backend/parser/parse_func.c
M src/backend/parser/parse_oper.c
M src/backend/parser/parse_param.c
M src/backend/parser/parse_relation.c
M src/backend/parser/parse_target.c
M src/backend/parser/parse_type.c
M src/backend/parser/parse_utilcmd.c
M src/backend/partitioning/partbounds.c
M src/backend/partitioning/partprune.c
M src/backend/port/sysv_sema.c
M src/backend/port/sysv_shmem.c
M src/backend/postmaster/autovacuum.c
M src/backend/postmaster/pgstat.c
M src/backend/postmaster/postmaster.c
M src/backend/postmaster/syslogger.c
M src/backend/regex/regcomp.c
M src/backend/regex/regprefix.c
M src/backend/replication/basebackup.c
M src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
M src/backend/replication/logical/decode.c
M src/backend/replication/logical/logical.c
M src/backend/replication/logical/proto.c
M src/backend/replication/logical/reorderbuffer.c
M src/backend/replication/pgoutput/pgoutput.c
M src/backend/replication/syncrep.c
M src/backend/rewrite/rewriteDefine.c
M src/backend/rewrite/rewriteHandler.c
M src/backend/rewrite/rewriteManip.c
M src/backend/rewrite/rowsecurity.c
M src/backend/statistics/dependencies.c
M src/backend/statistics/extended_stats.c
M src/backend/statistics/mcv.c
M src/backend/statistics/mvdistinct.c
M src/backend/storage/buffer/bufmgr.c
M src/backend/storage/buffer/freelist.c
M src/backend/storage/file/fd.c
M src/backend/storage/file/reinit.c
M src/backend/storage/freespace/freespace.c
M src/backend/storage/ipc/dsm.c
M src/backend/storage/ipc/dsm_impl.c
M src/backend/storage/ipc/latch.c
M src/backend/storage/ipc/procarray.c
M src/backend/storage/ipc/shm_mq.c
M src/backend/storage/ipc/standby.c
M src/backend/storage/lmgr/deadlock.c
M src/backend/storage/lmgr/lock.c
M src/backend/storage/lmgr/predicate.c
M src/backend/storage/smgr/md.c
M src/backend/tcop/fastpath.c
M src/backend/tcop/pquery.c
M src/backend/tcop/utility.c
M src/backend/tsearch/ts_selfuncs.c
M src/backend/tsearch/ts_typanalyze.c
M src/backend/utils/adt/acl.c
M src/backend/utils/adt/array_expanded.c
M src/backend/utils/adt/array_selfuncs.c
M src/backend/utils/adt/array_typanalyze.c
M src/backend/utils/adt/arrayfuncs.c
M src/backend/utils/adt/ascii.c
M src/backend/utils/adt/datetime.c
M src/backend/utils/adt/expandedrecord.c
M src/backend/utils/adt/formatting.c
M src/backend/utils/adt/geo_ops.c
M src/backend/utils/adt/inet_cidr_ntop.c
M src/backend/utils/adt/json.c
M src/backend/utils/adt/jsonb.c
M src/backend/utils/adt/jsonb_gin.c
M src/backend/utils/adt/jsonb_util.c
M src/backend/utils/adt/jsonfuncs.c
M src/backend/utils/adt/jsonpath.c
M src/backend/utils/adt/jsonpath_exec.c
M src/backend/utils/adt/like.c
M src/backend/utils/adt/like_support.c
M src/backend/utils/adt/network.c
M src/backend/utils/adt/network_selfuncs.c
M src/backend/utils/adt/network_spgist.c
M src/backend/utils/adt/numeric.c
M src/backend/utils/adt/oracle_compat.c
M src/backend/utils/adt/rangetypes.c
M src/backend/utils/adt/rangetypes_gist.c
M src/backend/utils/adt/rangetypes_selfuncs.c
M src/backend/utils/adt/rangetypes_spgist.c
M src/backend/utils/adt/rangetypes_typanalyze.c
M src/backend/utils/adt/regexp.c
M src/backend/utils/adt/regproc.c
M src/backend/utils/adt/ri_triggers.c
M src/backend/utils/adt/ruleutils.c
M src/backend/utils/adt/selfuncs.c
M src/backend/utils/adt/varbit.c
M src/backend/utils/adt/varlena.c
M src/backend/utils/adt/windowfuncs.c
M src/backend/utils/adt/xml.c
M src/backend/utils/cache/catcache.c
M src/backend/utils/cache/evtcache.c
M src/backend/utils/cache/plancache.c
M src/backend/utils/cache/relcache.c
M src/backend/utils/cache/relmapper.c
M src/backend/utils/cache/typcache.c
M src/backend/utils/fmgr/dfmgr.c
M src/backend/utils/fmgr/fmgr.c
M src/backend/utils/fmgr/funcapi.c
M src/backend/utils/mb/mbutils.c
M src/backend/utils/misc/guc.c
M src/backend/utils/misc/tzparser.c
M src/backend/utils/mmgr/aset.c
M src/backend/utils/mmgr/dsa.c
M src/backend/utils/mmgr/freepage.c
M src/backend/utils/mmgr/generation.c
M src/backend/utils/mmgr/mcxt.c
M src/backend/utils/mmgr/slab.c
M src/backend/utils/resowner/resowner.c
M src/backend/utils/sort/logtape.c
M src/backend/utils/sort/sharedtuplestore.c
M src/backend/utils/sort/tuplesort.c
M src/backend/utils/sort/tuplestore.c
M src/backend/utils/time/snapmgr.c
M src/bin/initdb/findtimezone.c
M src/bin/initdb/initdb.c
M src/bin/pg_basebackup/pg_basebackup.c
M src/bin/pg_basebackup/pg_receivewal.c
M src/bin/pg_basebackup/pg_recvlogical.c
M src/bin/pg_basebackup/receivelog.c
M src/bin/pg_basebackup/receivelog.h
M src/bin/pg_basebackup/streamutil.h
M src/bin/pg_basebackup/walmethods.h
M src/bin/pg_dump/common.c
M src/bin/pg_dump/compress_io.c
M src/bin/pg_dump/compress_io.h
M src/bin/pg_dump/dumputils.c
M src/bin/pg_dump/dumputils.h
M src/bin/pg_dump/parallel.c
M src/bin/pg_dump/parallel.h
M src/bin/pg_dump/pg_backup.h
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_backup_archiver.h
M src/bin/pg_dump/pg_backup_db.h
M src/bin/pg_dump/pg_backup_directory.c
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h
M src/bin/pg_dump/pg_dump_sort.c
M src/bin/pg_dump/pg_dumpall.c
M src/bin/pg_rewind/copy_fetch.c
M src/bin/pg_rewind/filemap.c
M src/bin/pg_rewind/filemap.h
M src/bin/pg_rewind/parsexlog.c
M src/bin/pg_rewind/pg_rewind.c
M src/bin/pg_rewind/pg_rewind.h
M src/bin/pg_upgrade/info.c
M src/bin/pg_upgrade/option.c
M src/bin/pg_upgrade/pg_upgrade.h
M src/bin/pgbench/pgbench.c
M src/bin/pgbench/pgbench.h
M src/bin/psql/command.c
M src/bin/psql/command.h
M src/bin/psql/common.h
M src/bin/psql/copy.h
M src/bin/psql/crosstabview.c
M src/bin/psql/describe.c
M src/bin/psql/startup.c
M src/bin/psql/stringutils.h
M src/bin/psql/tab-complete.c
M src/bin/psql/variables.h
M src/bin/scripts/clusterdb.c
M src/bin/scripts/common.h
M src/bin/scripts/reindexdb.c
M src/bin/scripts/vacuumdb.c
M src/common/file_utils.c
M src/common/ip.c
M src/fe_utils/print.c
M src/include/access/amvalidate.h
M src/include/access/brin_internal.h
M src/include/access/brin_pageops.h
M src/include/access/brin_revmap.h
M src/include/access/brin_tuple.h
M src/include/access/clog.h
M src/include/access/commit_ts.h
M src/include/access/genam.h
M src/include/access/generic_xlog.h
M src/include/access/gin.h
M src/include/access/gin_private.h
M src/include/access/gist_private.h
M src/include/access/gistscan.h
M src/include/access/hash.h
M src/include/access/heapam.h
M src/include/access/heapam_xlog.h
M src/include/access/hio.h
M src/include/access/htup.h
M src/include/access/htup_details.h
M src/include/access/itup.h
M src/include/access/multixact.h
M src/include/access/nbtree.h
M src/include/access/parallel.h
M src/include/access/printsimple.h
M src/include/access/printtup.h
M src/include/access/relation.h
M src/include/access/reloptions.h
M src/include/access/rewriteheap.h
M src/include/access/skey.h
M src/include/access/slru.h
M src/include/access/spgist.h
M src/include/access/spgist_private.h
M src/include/access/table.h
M src/include/access/tableam.h
M src/include/access/timeline.h
M src/include/access/transam.h
M src/include/access/tupconvert.h
M src/include/access/tupdesc.h
M src/include/access/tuptoaster.h
M src/include/access/twophase.h
M src/include/access/twophase_rmgr.h
M src/include/access/visibilitymap.h
M src/include/access/xact.h
M src/include/access/xlog.h
M src/include/access/xlog_internal.h
M src/include/access/xloginsert.h
M src/include/access/xlogreader.h
M src/include/access/xlogutils.h
M src/include/bootstrap/bootstrap.h
M src/include/c.h
M src/include/catalog/catalog.h
M src/include/catalog/dependency.h
M src/include/catalog/heap.h
M src/include/catalog/index.h
M src/include/catalog/indexing.h
M src/include/catalog/namespace.h
M src/include/catalog/objectaccess.h
M src/include/catalog/objectaddress.h
M src/include/catalog/partition.h
M src/include/catalog/pg_aggregate.h
M src/include/catalog/pg_collation.h
M src/include/catalog/pg_constraint.h
M src/include/catalog/pg_conversion.h
M src/include/catalog/pg_db_role_setting.h
M src/include/catalog/pg_enum.h
M src/include/catalog/pg_inherits.h
M src/include/catalog/pg_operator.h
M src/include/catalog/pg_proc.h
M src/include/catalog/pg_publication.h
M src/include/catalog/pg_range.h
M src/include/catalog/pg_subscription_rel.h
M src/include/catalog/pg_type.h
M src/include/catalog/storage.h
M src/include/catalog/toasting.h
M src/include/commands/alter.h
M src/include/commands/async.h
M src/include/commands/cluster.h
M src/include/commands/copy.h
M src/include/commands/createas.h
M src/include/commands/defrem.h
M src/include/commands/event_trigger.h
M src/include/commands/explain.h
M src/include/commands/extension.h
M src/include/commands/matview.h
M src/include/commands/policy.h
M src/include/commands/portalcmds.h
M src/include/commands/prepare.h
M src/include/commands/schemacmds.h
M src/include/commands/seclabel.h
M src/include/commands/subscriptioncmds.h
M src/include/commands/tablecmds.h
M src/include/commands/trigger.h
M src/include/commands/typecmds.h
M src/include/commands/vacuum.h
M src/include/commands/view.h
M src/include/common/config_info.h
M src/include/common/controldata_utils.h
M src/include/common/ip.h
M src/include/common/md5.h
M src/include/common/pg_lzcompress.h
M src/include/common/relpath.h
M src/include/common/scram-common.h
M src/include/common/sha2.h
M src/include/common/string.h
M src/include/executor/execExpr.h
M src/include/executor/execParallel.h
M src/include/executor/execPartition.h
M src/include/executor/execdesc.h
M src/include/executor/executor.h
M src/include/executor/functions.h
M src/include/executor/nodeBitmapHeapscan.h
M src/include/executor/nodeCustom.h
M src/include/executor/nodeForeignscan.h
M src/include/executor/nodeGatherMerge.h
M src/include/executor/nodeHash.h
M src/include/executor/nodeHashjoin.h
M src/include/executor/nodeIndexonlyscan.h
M src/include/executor/nodeIndexscan.h
M src/include/executor/nodeSeqscan.h
M src/include/executor/spi.h
M src/include/executor/tqueue.h
M src/include/executor/tstoreReceiver.h
M src/include/executor/tuptable.h
M src/include/fe_utils/mbprint.h
M src/include/fe_utils/print.h
M src/include/fe_utils/psqlscan.h
M src/include/fe_utils/psqlscan_int.h
M src/include/fe_utils/string_utils.h
M src/include/fmgr.h
M src/include/foreign/fdwapi.h
M src/include/foreign/foreign.h
M src/include/funcapi.h
M src/include/getaddrinfo.h
M src/include/getopt_long.h
M src/include/lib/binaryheap.h
M src/include/lib/bloomfilter.h
M src/include/lib/dshash.h
M src/include/lib/knapsack.h
M src/include/lib/pairingheap.h
M src/include/lib/rbtree.h
M src/include/lib/simplehash.h
M src/include/lib/stringinfo.h
M src/include/libpq/be-fsstubs.h
M src/include/libpq/crypt.h
M src/include/libpq/hba.h
M src/include/libpq/ifaddr.h
M src/include/libpq/libpq.h
M src/include/libpq/pqformat.h
M src/include/libpq/scram.h
M src/include/mb/pg_wchar.h
M src/include/miscadmin.h
M src/include/nodes/extensible.h
M src/include/nodes/makefuncs.h
M src/include/nodes/nodeFuncs.h
M src/include/nodes/nodes.h
M src/include/nodes/print.h
M src/include/nodes/tidbitmap.h
M src/include/optimizer/appendinfo.h
M src/include/optimizer/clauses.h
M src/include/optimizer/cost.h
M src/include/optimizer/geqo.h
M src/include/optimizer/geqo_recombination.h
M src/include/optimizer/geqo_selection.h
M src/include/optimizer/inherit.h
M src/include/optimizer/joininfo.h
M src/include/optimizer/optimizer.h
M src/include/optimizer/paramassign.h
M src/include/optimizer/pathnode.h
M src/include/optimizer/paths.h
M src/include/optimizer/placeholder.h
M src/include/optimizer/plancat.h
M src/include/optimizer/planmain.h
M src/include/optimizer/planner.h
M src/include/optimizer/restrictinfo.h
M src/include/optimizer/subselect.h
M src/include/optimizer/tlist.h
M src/include/parser/analyze.h
M src/include/parser/gramparse.h
M src/include/parser/parse_agg.h
M src/include/parser/parse_clause.h
M src/include/parser/parse_coerce.h
M src/include/parser/parse_cte.h
M src/include/parser/parse_func.h
M src/include/parser/parse_node.h
M src/include/parser/parse_oper.h
M src/include/parser/parse_param.h
M src/include/parser/parse_relation.h
M src/include/parser/parse_target.h
M src/include/parser/parse_type.h
M src/include/parser/parse_utilcmd.h
M src/include/parser/parsetree.h
M src/include/parser/scanner.h
M src/include/parser/scansup.h
M src/include/partitioning/partbounds.h
M src/include/partitioning/partdesc.h
M src/include/partitioning/partprune.h
M src/include/pgstat.h
M src/include/pgtar.h
M src/include/pgtime.h
M src/include/port.h
M src/include/postmaster/autovacuum.h
M src/include/postmaster/bgworker.h
M src/include/regex/regex.h
M src/include/regex/regexport.h
M src/include/replication/decode.h
M src/include/replication/logical.h
M src/include/replication/logicalfuncs.h
M src/include/replication/logicalproto.h
M src/include/replication/logicalrelation.h
M src/include/replication/message.h
M src/include/replication/origin.h
M src/include/replication/reorderbuffer.h
M src/include/replication/slot.h
M src/include/replication/snapbuild.h
M src/include/replication/walreceiver.h
M src/include/replication/worker_internal.h
M src/include/rewrite/rewriteDefine.h
M src/include/rewrite/rewriteHandler.h
M src/include/rewrite/rewriteManip.h
M src/include/rewrite/rowsecurity.h
M src/include/statistics/extended_stats_internal.h
M src/include/statistics/statistics.h
M src/include/storage/buf_internals.h
M src/include/storage/bufmgr.h
M src/include/storage/bufpage.h
M src/include/storage/dsm.h
M src/include/storage/dsm_impl.h
M src/include/storage/fd.h
M src/include/storage/freespace.h
M src/include/storage/fsm_internals.h
M src/include/storage/itemptr.h
M src/include/storage/latch.h
M src/include/storage/lmgr.h
M src/include/storage/lock.h
M src/include/storage/md.h
M src/include/storage/pg_shmem.h
M src/include/storage/predicate.h
M src/include/storage/predicate_internals.h
M src/include/storage/procarray.h
M src/include/storage/procsignal.h
M src/include/storage/reinit.h
M src/include/storage/sharedfileset.h
M src/include/storage/shm_mq.h
M src/include/storage/shmem.h
M src/include/storage/sinval.h
M src/include/storage/smgr.h
M src/include/storage/standby.h
M src/include/storage/standbydefs.h
M src/include/storage/sync.h
M src/include/tcop/pquery.h
M src/include/tcop/tcopprot.h
M src/include/tcop/utility.h
M src/include/tsearch/ts_locale.h
M src/include/tsearch/ts_public.h
M src/include/tsearch/ts_utils.h
M src/include/utils/acl.h
M src/include/utils/array.h
M src/include/utils/builtins.h
M src/include/utils/catcache.h
M src/include/utils/datetime.h
M src/include/utils/datum.h
M src/include/utils/dsa.h
M src/include/utils/elog.h
M src/include/utils/expandeddatum.h
M src/include/utils/expandedrecord.h
M src/include/utils/float.h
M src/include/utils/freepage.h
M src/include/utils/guc.h
M src/include/utils/guc_tables.h
M src/include/utils/hashutils.h
M src/include/utils/hsearch.h
M src/include/utils/index_selfuncs.h
M src/include/utils/inval.h
M src/include/utils/jsonapi.h
M src/include/utils/jsonb.h
M src/include/utils/jsonpath.h
M src/include/utils/logtape.h
M src/include/utils/lsyscache.h
M src/include/utils/memutils.h
M src/include/utils/numeric.h
M src/include/utils/palloc.h
M src/include/utils/pg_locale.h
M src/include/utils/plancache.h
M src/include/utils/portal.h
M src/include/utils/ps_status.h
M src/include/utils/rangetypes.h
M src/include/utils/regproc.h
M src/include/utils/relcache.h
M src/include/utils/relmapper.h
M src/include/utils/resowner.h
M src/include/utils/resowner_private.h
M src/include/utils/ruleutils.h
M src/include/utils/sampling.h
M src/include/utils/selfuncs.h
M src/include/utils/sharedtuplestore.h
M src/include/utils/snapmgr.h
M src/include/utils/sortsupport.h
M src/include/utils/spccache.h
M src/include/utils/syscache.h
M src/include/utils/timestamp.h
M src/include/utils/tuplesort.h
M src/include/utils/tuplestore.h
M src/include/utils/typcache.h
M src/include/utils/varlena.h
M src/include/utils/xml.h
M src/include/windowapi.h
M src/interfaces/ecpg/ecpglib/ecpglib_extern.h
M src/interfaces/ecpg/ecpglib/prepare.c
M src/interfaces/ecpg/pgtypeslib/dt.h
M src/interfaces/ecpg/preproc/type.c
M src/interfaces/ecpg/preproc/type.h
M src/interfaces/libpq/fe-auth-scram.c
M src/interfaces/libpq/fe-auth.h
M src/interfaces/libpq/fe-connect.c
M src/interfaces/libpq/fe-exec.c
M src/interfaces/libpq/fe-gssapi-common.h
M src/interfaces/libpq/fe-misc.c
M src/interfaces/libpq/fe-print.c
M src/interfaces/libpq/fe-protocol3.c
M src/interfaces/libpq/fe-secure-common.h
M src/interfaces/libpq/fe-secure-openssl.c
M src/interfaces/libpq/libpq-events.h
M src/interfaces/libpq/libpq-fe.h
M src/interfaces/libpq/libpq-int.h
M src/interfaces/libpq/pqexpbuffer.h
M src/pl/plperl/plperl.c
M src/pl/plpgsql/src/pl_comp.c
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpgsql/src/plpgsql.h
M src/pl/plpython/plpy_elog.c
M src/pl/plpython/plpy_elog.h
M src/pl/plpython/plpy_exec.c
M src/pl/plpython/plpy_plpymodule.c
M src/pl/plpython/plpy_spi.c
M src/pl/plpython/plpy_typeio.c
M src/pl/plpython/plpy_typeio.h
M src/pl/tcl/pltcl.c
M src/port/inet_net_ntop.c
M src/port/path.c
M src/port/qsort.c
M src/port/qsort_arg.c
M src/port/snprintf.c
M src/test/isolation/isolationtester.c
M src/test/modules/test_shm_mq/setup.c
M src/test/modules/test_shm_mq/test.c
M src/test/modules/test_shm_mq/test_shm_mq.h
M src/test/modules/test_shm_mq/worker.c
M src/test/regress/pg_regress.h
M src/timezone/localtime.c
M src/timezone/pgtz.c
M src/timezone/pgtz.h
M src/timezone/strftime.c
M src/timezone/zic.c
M src/tools/pgindent/pgindent
M src/tutorial/funcs.c
Initial pgindent run for v12.
commit : be76af171cdb3e7465c4ef234af403f97ad79b7b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 12:55:34 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 12:55:34 -0400
This is still using the 2.0 version of pg_bsd_indent.
I thought it would be good to commit this separately,
so as to document the differences between 2.0 and 2.1 behavior.
Discussion: https://postgr.es/m/16296.1558103386@sss.pgh.pa.us
M contrib/amcheck/verify_nbtree.c
M contrib/cube/cube.c
M contrib/file_fdw/file_fdw.c
M contrib/intarray/_int_gist.c
M contrib/intarray/_int_tool.c
M contrib/pg_stat_statements/pg_stat_statements.c
M contrib/pgcrypto/imath.c
M contrib/pgcrypto/imath.h
M contrib/pgstattuple/pgstattuple.c
M contrib/postgres_fdw/postgres_fdw.c
M src/backend/access/common/heaptuple.c
M src/backend/access/gin/ginvacuum.c
M src/backend/access/gin/ginxlog.c
M src/backend/access/gist/gistutil.c
M src/backend/access/hash/hashfunc.c
M src/backend/access/heap/heapam.c
M src/backend/access/heap/heapam_handler.c
M src/backend/access/heap/rewriteheap.c
M src/backend/access/heap/tuptoaster.c
M src/backend/access/heap/vacuumlazy.c
M src/backend/access/nbtree/nbtinsert.c
M src/backend/access/nbtree/nbtsearch.c
M src/backend/access/nbtree/nbtsort.c
M src/backend/access/nbtree/nbtutils.c
M src/backend/access/spgist/spgscan.c
M src/backend/access/spgist/spgtextproc.c
M src/backend/access/spgist/spgvacuum.c
M src/backend/access/table/tableam.c
M src/backend/access/transam/xact.c
M src/backend/access/transam/xlog.c
M src/backend/catalog/aclchk.c
M src/backend/catalog/catalog.c
M src/backend/catalog/heap.c
M src/backend/catalog/index.c
M src/backend/catalog/objectaddress.c
M src/backend/catalog/pg_aggregate.c
M src/backend/catalog/pg_proc.c
M src/backend/catalog/pg_publication.c
M src/backend/catalog/storage.c
M src/backend/commands/amcmds.c
M src/backend/commands/cluster.c
M src/backend/commands/constraint.c
M src/backend/commands/dbcommands.c
M src/backend/commands/explain.c
M src/backend/commands/extension.c
M src/backend/commands/indexcmds.c
M src/backend/commands/statscmds.c
M src/backend/commands/tablecmds.c
M src/backend/commands/tablespace.c
M src/backend/commands/trigger.c
M src/backend/commands/vacuum.c
M src/backend/executor/execExpr.c
M src/backend/executor/execExprInterp.c
M src/backend/executor/execMain.c
M src/backend/executor/execParallel.c
M src/backend/executor/execPartition.c
M src/backend/executor/execReplication.c
M src/backend/executor/execScan.c
M src/backend/executor/execTuples.c
M src/backend/executor/functions.c
M src/backend/executor/nodeAgg.c
M src/backend/executor/nodeGatherMerge.c
M src/backend/executor/nodeHashjoin.c
M src/backend/executor/nodeIndexonlyscan.c
M src/backend/executor/nodeIndexscan.c
M src/backend/executor/nodeLockRows.c
M src/backend/executor/nodeModifyTable.c
M src/backend/executor/nodeSeqscan.c
M src/backend/executor/nodeSubplan.c
M src/backend/executor/nodeSubqueryscan.c
M src/backend/libpq/auth.c
M src/backend/libpq/be-secure-openssl.c
M src/backend/nodes/bitmapset.c
M src/backend/optimizer/path/clausesel.c
M src/backend/optimizer/util/inherit.c
M src/backend/optimizer/util/pathnode.c
M src/backend/parser/parse_utilcmd.c
M src/backend/partitioning/partdesc.c
M src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
M src/backend/replication/logical/reorderbuffer.c
M src/backend/replication/slotfuncs.c
M src/backend/replication/syncrep.c
M src/backend/replication/walreceiver.c
M src/backend/replication/walsender.c
M src/backend/statistics/dependencies.c
M src/backend/statistics/extended_stats.c
M src/backend/statistics/mcv.c
M src/backend/storage/buffer/bufmgr.c
M src/backend/storage/file/fd.c
M src/backend/storage/ipc/latch.c
M src/backend/storage/ipc/pmsignal.c
M src/backend/storage/ipc/signalfuncs.c
M src/backend/storage/lmgr/lmgr.c
M src/backend/storage/smgr/smgr.c
M src/backend/storage/sync/sync.c
M src/backend/tcop/dest.c
M src/backend/utils/adt/formatting.c
M src/backend/utils/adt/genfile.c
M src/backend/utils/adt/geo_ops.c
M src/backend/utils/adt/json.c
M src/backend/utils/adt/jsonb.c
M src/backend/utils/adt/like.c
M src/backend/utils/adt/like_support.c
M src/backend/utils/adt/numutils.c
M src/backend/utils/adt/regexp.c
M src/backend/utils/adt/ri_triggers.c
M src/backend/utils/adt/ruleutils.c
M src/backend/utils/adt/varchar.c
M src/backend/utils/adt/varlena.c
M src/backend/utils/cache/relcache.c
M src/backend/utils/cache/relmapper.c
M src/backend/utils/cache/syscache.c
M src/backend/utils/fmgr/fmgr.c
M src/backend/utils/hash/hashfn.c
M src/backend/utils/init/globals.c
M src/backend/utils/init/miscinit.c
M src/backend/utils/mb/mbutils.c
M src/backend/utils/misc/guc.c
M src/backend/utils/mmgr/dsa.c
M src/bin/initdb/initdb.c
M src/bin/pg_archivecleanup/pg_archivecleanup.c
M src/bin/pg_basebackup/pg_receivewal.c
M src/bin/pg_basebackup/pg_recvlogical.c
M src/bin/pg_basebackup/receivelog.c
M src/bin/pg_dump/common.c
M src/bin/pg_dump/compress_io.c
M src/bin/pg_dump/parallel.c
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_backup_custom.c
M src/bin/pg_dump/pg_backup_db.c
M src/bin/pg_dump/pg_backup_directory.c
M src/bin/pg_dump/pg_backup_tar.c
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dumpall.c
M src/bin/pg_dump/pg_restore.c
M src/bin/pg_rewind/filemap.c
M src/bin/pg_rewind/libpq_fetch.c
M src/bin/pg_rewind/parsexlog.c
M src/bin/pg_rewind/pg_rewind.c
M src/bin/pg_upgrade/controldata.c
M src/bin/pg_upgrade/function.c
M src/bin/pg_waldump/pg_waldump.c
M src/bin/pgbench/pgbench.c
M src/bin/psql/command.c
M src/bin/psql/common.c
M src/bin/psql/copy.c
M src/bin/psql/crosstabview.c
M src/bin/psql/describe.c
M src/bin/psql/startup.c
M src/bin/psql/tab-complete.c
M src/bin/psql/variables.c
M src/common/d2s.c
M src/common/f2s.c
M src/common/file_utils.c
M src/common/logging.c
M src/common/pg_lzcompress.c
M src/common/rmtree.c
M src/include/access/amapi.h
M src/include/access/gistxlog.h
M src/include/access/hio.h
M src/include/access/relscan.h
M src/include/access/spgist_private.h
M src/include/access/spgxlog.h
M src/include/access/tableam.h
M src/include/access/tupdesc.h
M src/include/access/xlog.h
M src/include/access/xlog_internal.h
M src/include/catalog/dependency.h
M src/include/catalog/index.h
M src/include/catalog/pg_attrdef.h
M src/include/catalog/pg_default_acl.h
M src/include/catalog/pg_policy.h
M src/include/catalog/storage.h
M src/include/commands/defrem.h
M src/include/commands/trigger.h
M src/include/commands/vacuum.h
M src/include/common/file_utils.h
M src/include/common/logging.h
M src/include/executor/execParallel.h
M src/include/executor/executor.h
M src/include/executor/tuptable.h
M src/include/libpq/libpq-be.h
M src/include/miscadmin.h
M src/include/nodes/execnodes.h
M src/include/nodes/parsenodes.h
M src/include/nodes/plannodes.h
M src/include/parser/parse_node.h
M src/include/pgstat.h
M src/include/port.h
M src/include/replication/logical.h
M src/include/replication/reorderbuffer.h
M src/include/statistics/extended_stats_internal.h
M src/include/statistics/statistics.h
M src/include/storage/fd.h
M src/include/storage/md.h
M src/include/tcop/deparse_utility.h
M src/include/utils/datum.h
M src/interfaces/ecpg/ecpglib/cursor.c
M src/interfaces/ecpg/ecpglib/descriptor.c
M src/interfaces/ecpg/ecpglib/ecpglib_extern.h
M src/interfaces/ecpg/ecpglib/error.c
M src/interfaces/ecpg/ecpglib/execute.c
M src/interfaces/ecpg/ecpglib/prepare.c
M src/interfaces/ecpg/include/ecpglib.h
M src/interfaces/ecpg/preproc/ecpg.c
M src/interfaces/ecpg/preproc/output.c
M src/interfaces/ecpg/preproc/preproc_extern.h
M src/interfaces/ecpg/preproc/type.h
M src/interfaces/libpq/fe-connect.c
M src/interfaces/libpq/libpq-fe.h
M src/interfaces/libpq/pqexpbuffer.c
M src/pl/plpgsql/src/pl_exec.c
M src/pl/plpgsql/src/plpgsql.h
M src/pl/plpython/plpy_exec.c
M src/pl/tcl/pltcl.c
M src/port/dlopen.c
M src/port/pg_bitutils.c
M src/port/strtof.c
M src/test/regress/pg_regress.c
M src/test/regress/regress.c
M src/tools/pgindent/typedefs.list
Convert ExecComputeStoredGenerated to use tuple slots
commit : 66a4bad83aaa6613a45a00a488c04427f9969fb4
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 15 May 2019 19:37:52 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 15 May 2019 19:37:52 +0200
This code was still using the old style of forming a heap tuple rather
than using tuple slots. This would be less efficient if a non-heap
access method was used. And using tuple slots is actually quite a bit
faster when using heap as well.
Also add some test cases for generated columns with null values and
with varlena values. This lack of coverage was discovered while
working on this patch.
Discussion: https://www.postgresql.org/message-id/flat/20190331025744.ugbsyks7czfcoksd%40alap3.anarazel.de
M src/backend/executor/nodeModifyTable.c
M src/test/regress/expected/generated.out
M src/test/regress/sql/generated.sql
Mention ANALYZE boolean options in documentation.
commit : 03de5187d50af67d154a47cf00899290dca13003
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 23 May 2019 01:18:16 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 23 May 2019 01:18:16 +0900
Commit 41b54ba78e allowed not only VACUUM but also ANALYZE options
to take a boolean argument. But it forgot to update the documentation
for ANALYZE. This commit adds the descriptions about those ANALYZE
boolean options into the documentation.
This patch also updates tab-completion for ANALYZE boolean options.
Reported-by: Kyotaro Horiguchi
Author: Fujii Masao
Reviewed-by: Masahiko Sawada, Michael Paquier
Discussion: https://postgr.es/m/CAHGQGwHTUt-kuwgiwe8f0AvTnB+ySqJWh95jvmh-qcoKW9YA9g@mail.gmail.com
M doc/src/sgml/ref/analyze.sgml
M doc/src/sgml/release-12.sgml
M src/bin/psql/tab-complete.c
Fix O(N^2) performance issue in pg_publication_tables view.
commit : 166f69f769c83ef8759d905bf7f1a9aa1d97a340
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 11:46:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 11:46:57 -0400
The original coding of this view relied on a correlated IN sub-query.
Our planner is not very bright about correlated sub-queries, and even
if it were, there's no way for it to know that the output of
pg_get_publication_tables() is duplicate-free, making the de-duplicating
semantics of IN unnecessary. Hence, rewrite as a LATERAL sub-query.
This provides circa 100X speedup for me with a few hundred published
tables (the whole regression database), and things would degrade as
roughly O(published_relations * all_relations) beyond that.
Because the rules.out expected output changes, force a catversion bump.
Ordinarily we might not want to do that post-beta1; but we already know
we'll be doing a catversion bump before beta2 to fix pg_statistic_ext
issues, so it's pretty much free to fix it now instead of waiting for v13.
Per report and fix suggestion from PegoraroF10.
Discussion: https://postgr.es/m/1551385426763-0.post@n3.nabble.com
M src/backend/catalog/system_views.sql
M src/include/catalog/catversion.h
M src/test/regress/expected/rules.out
docs: PG 12 release notes, support functions
commit : 728840fe13acff7b03a4b1a813eeb8900ce5e469
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 22 May 2019 11:22:13 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 22 May 2019 11:22:13 -0400
Move support function mention to the proper section, and reword.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/5121.1558472431@sss.pgh.pa.us
M doc/src/sgml/release-12.sgml
doc: PG 12 relnotes, correct recovery_target* variable mention
commit : ba95a6933632410d103d6f17cd3bc1adf92a08f9
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 22 May 2019 10:54:40 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 22 May 2019 10:54:40 -0400
Clarify new restriction on recovery_target* variables.
Reported-by: Gaby Schilders
Discussion: reported via chat
M doc/src/sgml/release-12.sgml
Add .gitignore entries for new ecpg test case.
commit : 4a657ab260499381c645673ca1c3255adc0b2ace
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 10:42:24 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 10:42:24 -0400
Oversight in commit a1dc6ab465986a62b308dd1bb8da316b5ed9685a.
M src/interfaces/ecpg/test/sql/.gitignore
In transam.h, don't expose static inline functions to frontend code.
commit : 4fbf809e13c3ba09c4f03d148cb58767e56f67f1
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 10:38:21 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 22 May 2019 10:38:21 -0400
That leads to unsatisfied external references if the C compiler fails
to elide unused static functions. Apparently, we have no buildfarm
members building HEAD that have that issue ... but such compilers still
exist in the wild. Need to do something about that.
In passing, fix Berkeley-era typo in comment.
Discussion: https://postgr.es/m/27054.1558533367@sss.pgh.pa.us
M src/include/access/transam.h
Fix ordering of GRANT commands in pg_dump for database creation
commit : b8c6014a65ee0819e8fe4c7536f72da0df5d8e46
author : Michael Paquier <michael@paquier.xyz>
date : Wed, 22 May 2019 14:48:00 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Wed, 22 May 2019 14:48:00 +0900
This uses a method similar to 68a7c24f, which guarantees that GRANT
commands using the WITH GRANT OPTION are dumped in a way so as cascading
dependencies are respected. As databases do not have support for
initial privileges via pg_init_privs, we need to repeat again the same
ACL reordering method.
ACL for databases have been moved from pg_dumpall to pg_dump in v11, so
this impacts pg_dump for v11 and above, and pg_dumpall for v9.6 and
v10.
Discussion: https://postgr.es/m/15788-4e18847520ebcc75@postgresql.org
Author: Nathan Bossart
Reviewed-by: Haribabu Kommi
Backpatch-through: 9.6
M src/bin/pg_dump/pg_dump.c
Un-break pg_upgrade regression test.
commit : 5eb4a51cb15166392ca3ede6ec58f8f1f820ef53
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 May 2019 23:51:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 May 2019 23:51:19 -0400
Commit 5af2e976d removed a bit too much from the test.sh invocation.
Per buildfarm.
M src/bin/pg_upgrade/Makefile
Implement PREPARE AS statement for ECPG.
commit : a1dc6ab465986a62b308dd1bb8da316b5ed9685a
author : Michael Meskes <meskes@postgresql.org>
date : Wed, 22 May 2019 04:58:29 +0200
committer: Michael Meskes <meskes@postgresql.org>
date : Wed, 22 May 2019 04:58:29 +0200
Besides implementing the new statement this change fix some issues with the
parsing of PREPARE and EXECUTE statements. The different forms of these
statements are now all handled in a ujnified way.
Author: Matsumura-san <matsumura.ryo@jp.fujitsu.com>
M src/interfaces/ecpg/ecpglib/ecpglib_extern.h
M src/interfaces/ecpg/ecpglib/execute.c
M src/interfaces/ecpg/ecpglib/prepare.c
M src/interfaces/ecpg/include/ecpgtype.h
M src/interfaces/ecpg/preproc/check_rules.pl
M src/interfaces/ecpg/preproc/ecpg.addons
M src/interfaces/ecpg/preproc/ecpg.header
M src/interfaces/ecpg/preproc/output.c
M src/interfaces/ecpg/preproc/parse.pl
M src/interfaces/ecpg/preproc/type.h
M src/interfaces/ecpg/test/ecpg_schedule
A src/interfaces/ecpg/test/expected/sql-prepareas.c
A src/interfaces/ecpg/test/expected/sql-prepareas.stderr
A src/interfaces/ecpg/test/expected/sql-prepareas.stdout
M src/interfaces/ecpg/test/sql/Makefile
A src/interfaces/ecpg/test/sql/prepareas.pgc
pg_upgrade: Avoid check target accidentally breaking make's --output-sync.
commit : 5af2e976d72aa345337596cc986237c57e1146b2
author : Andres Freund <andres@anarazel.de>
date : Tue, 21 May 2019 15:03:27 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 21 May 2019 15:03:27 -0700
When $(MAKE) is present in a rule, make assumes that target is a
submake, and it doesn't need to buffer its output. But in this case
it's a shell script that needs buffered output. Avoid that heuristic,
by referring to $(MAKE) via an indirection.
Discussion: https://postgr.es/m/20190521004717.qsktdsugj3shagco@alap3.anarazel.de
M src/bin/pg_upgrade/Makefile
pg_upgrade: Don't use separate installation for test.
commit : 7005389b2ad17258bc3aa0a2427c4eb77fed1d09
author : Andres Freund <andres@anarazel.de>
date : Tue, 21 May 2019 14:56:29 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 21 May 2019 14:56:29 -0700
For pg_upgrade's test we (unless prevented by the caller via via
NO_TEMP_INSTALL) built a separate installation. That causes an
unnecessary slowdown after the infrastructure introduced by
dcae5faccab (and unnecessarily duplicates code).
Author: Andres Freund
Reviewed-By: Tom Lane
Discussion:
https://postgr.es/m/20190521191918.z7kwnrlj45mk2k67@alap3.anarazel.de
https://postgr.es/m/20190521195209.qfzwfxvymguuwlu5@alap3.anarazel.de
M src/bin/pg_upgrade/Makefile
M src/bin/pg_upgrade/test.sh
docs: PG 12 relnote adjustments based on feedback from Tom Lane
commit : 8e719d33fd253fc378871ba4dbf2de41fd2ba462
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 21 May 2019 16:45:48 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 21 May 2019 16:45:48 -0400
Discussion: https://postgr.es/m/22793.1558399695@sss.pgh.pa.us
M doc/src/sgml/release-12.sgml
docs: adjust RECORD PG 12 relnote item
commit : 3468a04a3e498bab755909505e8f7b6023bea493
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 21 May 2019 16:35:43 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 21 May 2019 16:35:43 -0400
Discussion: https://postgr.es/m/15486.1558393010@sss.pgh.pa.us
M doc/src/sgml/release-12.sgml
doc: adjust PG 12 relnotes item on float digit adjustment
commit : b84a801d6a6737e6d84326b77d98b498402ecad0
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 21 May 2019 16:31:02 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 21 May 2019 16:31:02 -0400
Discussion: https://postgr.es/m/87y330d8ty.fsf@news-spur.riddles.org.uk
M doc/src/sgml/release-12.sgml
doc: fix markup for PG 12 rel notes
commit : 0fca8285ea533fa669a372c91fdb42265dcf7435
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 21 May 2019 16:19:43 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 21 May 2019 16:19:43 -0400
M doc/src/sgml/release-12.sgml
doc: adjustments for PG 12 release notes
commit : 32fe2e3194c7198ca4afdb6bea4ffa12466612b1
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 21 May 2019 16:14:33 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 21 May 2019 16:14:33 -0400
Mostly commit messages, attribution, and text, all suggested by Andres
Freund.
Discussion: https://postgr.es/m/20190520221719.pqgld3krjc2docr5@alap3.anarazel.de
M doc/src/sgml/release-12.sgml
Make pg_upgrade's test.sh less chatty.
commit : eb9812f272db8e93416831e5254569b76edf8264
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 May 2019 13:11:57 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 May 2019 13:11:57 -0400
The use of "set -x" to echo a subset of the test's commands might've
been a good idea during development of this test, but it's been stable
for long enough now that the extra output isn't very useful. Also
our project expectations have been trending towards less output in
non-error cases; the fact that "set -x" produces output on stderr
is particularly annoying from that standpoint. So get rid of it.
Also, pass "-A trust" to initdb explicitly so that it won't issue
a warning about "trust" being an insecure default. This matches
what the TAP tests have done for a long time, and again gets rid
of some noise on stderr.
Discussion: https://postgr.es/m/21766.1558397960@sss.pgh.pa.us
M src/bin/pg_upgrade/test.sh
Insert temporary debugging output in regression tests.
commit : f03a9ca4366d064d89b7cf7ed75d4e43f2ed0667
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 May 2019 12:23:16 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 21 May 2019 12:23:16 -0400
We're seeing occasional instability in the plans generated for
parallel queries on the "a_star" table hierarchy. This suggests
that something is changing the planner's stats for those tables,
but that should not be happening within a regression test run.
To try to gather some information about what's happening, insert
additional queries to check the basic page/tuple counts for these
tables, as well as whether any vacuums or analyzes have happened
on them. (We expect that only the database-wide VACUUM in
sanity_check.sql will have touched them.)
I added the probes not only in select_parallel.sql itself, but
also in stats.sql, bearing in mind that the stats collector's
lag may prevent the initial query from reporting current truth.
If any extra vacuum/analyze has happened, the recheck in stats.sql
definitely ought to see it.
This commit can be reverted once we figure out what's going on.
Per suggestion from David Rowley, though I changed the queries around.
Discussion: https://postgr.es/m/CA+hUKG+0CxrKRWRMf5ymN3gm+BECHna2B-q1w8onKBep4HasUw@mail.gmail.com
M src/test/regress/expected/select_parallel.out
M src/test/regress/expected/stats.out
M src/test/regress/sql/select_parallel.sql
M src/test/regress/sql/stats.sql
tableam: Move heap-specific logic from needs_toast_table below tableam.
commit : 1171d7d58545f26a402f76a05936d572bf29d53b
author : Robert Haas <rhaas@postgresql.org>
date : Tue, 21 May 2019 11:57:13 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Tue, 21 May 2019 11:57:13 -0400
This allows table AMs to completely suppress TOAST table creation, or
to modify the conditions under which they are created.
Patch by me. Reviewed by Andres Freund.
Discussion: http://postgr.es/m/CA+Tgmoa4O2n=yphqD2pERUnYmUO84bH1SqMsA-nSxBGsZ7gWfA@mail.gmail.com
M src/backend/access/heap/heapam_handler.c
M src/backend/catalog/toasting.c
M src/include/access/tableam.h
Doc: improve description of regexp character classes.
commit : cf92226e9f7f985a678287167b954a831a3b660c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 20 May 2019 18:39:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 20 May 2019 18:39:53 -0400
Define the meanings of the POSIX-spec character classes in line,
rather than referring to the ctype(3) man page. That man page
doesn't even exist on many modern systems, and if it does exist
it probably says the wrong things about non-ASCII characters.
Also document our non-POSIX-spec "ascii" character class.
Also, point out here that this behavior is controlled by collation or
LC_CTYPE, since the existing text explaining that is pretty far away.
Per gripe from Geert Lobbestael. Given the lack of prior complaints,
I'm not excited about back-patching this.
Discussion: https://postgr.es/m/155837022049.1359.2948065118562813468@wrigleys.postgresql.org
M doc/src/sgml/func.sgml
Stamp 12beta1.
commit : a240570b1e3802d1e82da08a9d72abeade370249
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 20 May 2019 16:37:22 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 20 May 2019 16:37:22 -0400
M configure
M configure.in
M src/include/pg_config.h.win32
Fix regression tests broken in fc7c281f87467.
commit : 47a14c99e4715dde7f570d050e1ddb6d21278bf8
author : Andres Freund <andres@anarazel.de>
date : Mon, 20 May 2019 09:36:06 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 20 May 2019 09:36:06 -0700
This shouldn't have been committed without even running the tests (nor
were the tests added that were suggested). I'm fixing up the results
to get the buildfarm back to green, it's quite possible we'll want to
revert this later.
M src/test/regress/expected/vacuum.out
Fix comment for issue_xlog_fsync().
commit : b8e2170e40a151eb94079ce9cd791a712ed95342
author : Fujii Masao <fujii@postgresql.org>
date : Tue, 21 May 2019 00:44:00 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Tue, 21 May 2019 00:44:00 +0900
"segno" is the argument for the function, not "log" and "seg".
Author: Antonin Houska
Discussion: https://postgr.es/m/11863.1558361020@spoje.net
M src/backend/access/transam/xlog.c
Make VACUUM accept 1 and 0 as a boolean value.
commit : fc7c281f87467c1ff24fd72e0cc313dd6a71873f
author : Fujii Masao <fujii@postgresql.org>
date : Tue, 21 May 2019 00:22:06 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Tue, 21 May 2019 00:22:06 +0900
Commit 41b54ba78e allowed existing VACUUM options to take a boolean
argument. It's documented that valid boolean values that VACUUM can
accept are true, false, on, off, 1, and 0. But previously the parser
failed to accept 1 and 0 as a boolean value in VACUUM syntax because
of a lack of NumericOnly clause for vac_analyze_option_arg in gram.y.
This commit adds such NumericOnly clause so that VACUUM options
can take also 1 and 0 as a boolean value.
Discussion: https://postgr.es/m/CAHGQGwGYg82A8UCQxZe7Zn9MnyUBGdyB=1CNpKF3jBny+RbyfA@mail.gmail.com
M src/backend/parser/gram.y
Translation updates
commit : 3c439a58df83ae51f650cfae9878df1f9b70c4b8
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 20 May 2019 16:00:53 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 20 May 2019 16:00:53 +0200
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: a20bf6b8a5b4e32450967055eb5b07cee4704edd
M src/backend/nls.mk
M src/backend/po/de.po
M src/backend/po/es.po
M src/backend/po/fr.po
M src/backend/po/it.po
M src/backend/po/ja.po
M src/backend/po/ko.po
M src/backend/po/ru.po
M src/backend/po/sv.po
A src/backend/po/tr.po
M src/bin/initdb/po/de.po
M src/bin/initdb/po/es.po
M src/bin/initdb/po/fr.po
M src/bin/initdb/po/sv.po
M src/bin/pg_archivecleanup/po/de.po
M src/bin/pg_archivecleanup/po/es.po
M src/bin/pg_archivecleanup/po/fr.po
M src/bin/pg_archivecleanup/po/sv.po
M src/bin/pg_basebackup/po/de.po
M src/bin/pg_basebackup/po/es.po
M src/bin/pg_basebackup/po/sv.po
M src/bin/pg_checksums/nls.mk
A src/bin/pg_checksums/po/es.po
A src/bin/pg_checksums/po/sv.po
M src/bin/pg_config/po/cs.po
M src/bin/pg_config/po/es.po
M src/bin/pg_config/po/fr.po
M src/bin/pg_config/po/ja.po
M src/bin/pg_config/po/sv.po
M src/bin/pg_config/po/tr.po
M src/bin/pg_controldata/po/cs.po
M src/bin/pg_controldata/po/de.po
M src/bin/pg_controldata/po/es.po
M src/bin/pg_controldata/po/fr.po
M src/bin/pg_controldata/po/it.po
M src/bin/pg_controldata/po/ja.po
M src/bin/pg_controldata/po/ko.po
M src/bin/pg_controldata/po/ru.po
M src/bin/pg_controldata/po/sv.po
M src/bin/pg_controldata/po/tr.po
M src/bin/pg_ctl/po/cs.po
M src/bin/pg_ctl/po/es.po
M src/bin/pg_ctl/po/fr.po
M src/bin/pg_ctl/po/he.po
M src/bin/pg_ctl/po/it.po
M src/bin/pg_ctl/po/ja.po
M src/bin/pg_ctl/po/ko.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_ctl/po/sv.po
M src/bin/pg_ctl/po/tr.po
M src/bin/pg_dump/po/es.po
M src/bin/pg_dump/po/sv.po
M src/bin/pg_resetwal/po/de.po
M src/bin/pg_resetwal/po/es.po
M src/bin/pg_resetwal/po/sv.po
M src/bin/pg_rewind/po/es.po
M src/bin/pg_rewind/po/sv.po
M src/bin/pg_test_fsync/nls.mk
A src/bin/pg_test_fsync/po/cs.po
M src/bin/pg_test_fsync/po/es.po
M src/bin/pg_test_fsync/po/ru.po
M src/bin/pg_test_fsync/po/tr.po
M src/bin/pg_test_timing/nls.mk
A src/bin/pg_test_timing/po/cs.po
M src/bin/pg_test_timing/po/es.po
M src/bin/pg_upgrade/nls.mk
A src/bin/pg_upgrade/po/cs.po
M src/bin/pg_upgrade/po/de.po
A src/bin/pg_upgrade/po/es.po
M src/bin/pg_upgrade/po/fr.po
M src/bin/pg_upgrade/po/ja.po
M src/bin/pg_upgrade/po/ko.po
M src/bin/pg_upgrade/po/ru.po
M src/bin/pg_upgrade/po/sv.po
M src/bin/pg_upgrade/po/tr.po
M src/bin/pg_waldump/po/de.po
M src/bin/pg_waldump/po/es.po
M src/bin/pg_waldump/po/fr.po
M src/bin/pg_waldump/po/sv.po
M src/bin/psql/nls.mk
M src/bin/psql/po/cs.po
M src/bin/psql/po/de.po
M src/bin/psql/po/es.po
M src/bin/psql/po/fr.po
M src/bin/psql/po/it.po
M src/bin/psql/po/ja.po
M src/bin/psql/po/ru.po
M src/bin/psql/po/sv.po
A src/bin/psql/po/tr.po
M src/bin/scripts/po/de.po
M src/bin/scripts/po/es.po
M src/bin/scripts/po/sv.po
M src/interfaces/ecpg/ecpglib/po/cs.po
M src/interfaces/ecpg/ecpglib/po/es.po
M src/interfaces/ecpg/ecpglib/po/fr.po
M src/interfaces/ecpg/ecpglib/po/ru.po
M src/interfaces/ecpg/ecpglib/po/sv.po
M src/interfaces/ecpg/preproc/po/cs.po
M src/interfaces/ecpg/preproc/po/es.po
M src/interfaces/ecpg/preproc/po/fr.po
M src/interfaces/ecpg/preproc/po/it.po
M src/interfaces/ecpg/preproc/po/ja.po
M src/interfaces/ecpg/preproc/po/ko.po
M src/interfaces/ecpg/preproc/po/ru.po
M src/interfaces/ecpg/preproc/po/sv.po
M src/interfaces/ecpg/preproc/po/tr.po
M src/interfaces/libpq/po/cs.po
M src/interfaces/libpq/po/de.po
M src/interfaces/libpq/po/es.po
M src/interfaces/libpq/po/fr.po
M src/interfaces/libpq/po/he.po
M src/interfaces/libpq/po/it.po
M src/interfaces/libpq/po/ja.po
M src/interfaces/libpq/po/ko.po
M src/interfaces/libpq/po/ru.po
M src/interfaces/libpq/po/sv.po
M src/interfaces/libpq/po/tr.po
M src/pl/plperl/po/cs.po
M src/pl/plperl/po/de.po
M src/pl/plperl/po/es.po
M src/pl/plperl/po/fr.po
M src/pl/plperl/po/it.po
M src/pl/plperl/po/ru.po
M src/pl/plperl/po/sv.po
M src/pl/plpgsql/src/po/cs.po
M src/pl/plpgsql/src/po/de.po
M src/pl/plpgsql/src/po/es.po
M src/pl/plpgsql/src/po/fr.po
M src/pl/plpgsql/src/po/it.po
M src/pl/plpgsql/src/po/ja.po
M src/pl/plpgsql/src/po/ko.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpgsql/src/po/sv.po
M src/pl/plpgsql/src/po/tr.po
M src/pl/plpython/po/cs.po
M src/pl/plpython/po/de.po
M src/pl/plpython/po/es.po
M src/pl/plpython/po/fr.po
M src/pl/plpython/po/it.po
M src/pl/plpython/po/ja.po
M src/pl/plpython/po/ko.po
M src/pl/plpython/po/ru.po
M src/pl/plpython/po/sv.po
M src/pl/plpython/po/tr.po
M src/pl/plpython/po/vi.po
M src/pl/tcl/po/cs.po
M src/pl/tcl/po/es.po
M src/pl/tcl/po/fr.po
M src/pl/tcl/po/ru.po
M src/pl/tcl/po/sv.po
Remove bug.template file
commit : 8bbb8166b63eeebd0cb618ddcf7dcaf8c4ba66f4
author : Peter Eisentraut <peter@eisentraut.org>
date : Mon, 20 May 2019 08:33:31 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Mon, 20 May 2019 08:33:31 +0200
It's outdated and not really in use anymore.
Discussion: https://www.postgresql.org/message-id/flat/cf7ed2b1-1ebe-83cf-e05e-d5943f67af2d%402ndquadrant.com
M .gitattributes
D doc/bug.template
M src/tools/version_stamp.pl
Remove outdated comment in copy.c.
commit : fb504c5e4b5ce71e703006375ee2f5e4b57d89c9
author : Andres Freund <andres@anarazel.de>
date : Sun, 19 May 2019 20:47:54 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sun, 19 May 2019 20:47:54 -0700
M src/backend/commands/copy.c
Minimally fix partial aggregation for aggregates that don't have one argument.
commit : 2657283256f1cab53d09d2c7db1ce9b7065193a0
author : Andres Freund <andres@anarazel.de>
date : Sun, 19 May 2019 18:01:06 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sun, 19 May 2019 18:01:06 -0700
For partial aggregation combine steps,
AggStatePerTrans->numTransInputs was set to the transition function's
number of inputs, rather than the combine function's number of
inputs (always 1).
That lead to partial aggregates with strict combine functions to
wrongly check for NOT NULL input as required by strictness. When the
aggregate wasn't exactly passed one argument, the strictness check was
either omitted (in the 0 args case) or too many arguments were
checked. In the latter case we'd read beyond the end of
FunctionCallInfoData->args (only in master).
AggStatePerTrans->numTransInputs actually has been wrong since since
9.6, where partial aggregates were added. But it turns out to not be
an active problem in 9.6 and 10, because numTransInputs wasn't used at
all for combine functions: Before c253b722f6 there simply was no NULL
check for the input to strict trans functions, and after that the
check was simply hardcoded for the right offset in fcinfo, as it's
done by code specific to combine functions.
In bf6c614a2f2 (11) the strictness check was generalized, with common
code doing the strictness checks for both plain and combine transition
functions, based on numTransInputs. For combine functions this lead to
not emitting an expression step to check for strict input in the 0
arguments case, and in the > 1 arguments case, we'd check too many
arguments.Due to the fact that the relevant fcinfo->isnull[2..] was
always zero-initialized (more or less by accident, by being part of
the AggStatePerTrans struct, which is palloc0'ed), there was no
observable damage in the latter case before a9c35cf85ca1f, we just
checked too many array elements.
Due to the changes in a9c35cf85ca1f, > 1 argument bug became visible,
because these days fcinfo is a) dynamically allocated without being
zeroed b) exactly the length required for the number of specified
arguments (hardcoded to 2 in this case).
This commit only contains a fairly minimal fix, setting numTransInputs
to a hardcoded 1 when building a pertrans for a combine function. It
seems likely that we'll want to clean this up further (e.g. the
arguments build_pertrans_for_aggref() aren't particularly meaningful
for combine functions). But the wrap date for 12 beta1 is coming up
fast, so it seems good to have a minimal fix in place.
Backpatch to 11. While AggStatePerTrans->numTransInputs was set
wrongly before that, the value was not used for combine functions.
Reported-By: Rajkumar Raghuwanshi
Diagnosed-By: Kyotaro Horiguchi, Jeevan Chalke, Andres Freund, David Rowley
Author: David Rowley, Kyotaro Horiguchi, Andres Freund
Discussion: https://postgr.es/m/CAKcux6=uZEyWyLw0N7HtR9OBc-sWEFeByEZC7t-KDf15FKxVew@mail.gmail.com
M src/backend/executor/nodeAgg.c
M src/test/regress/expected/aggregates.out
M src/test/regress/sql/aggregates.sql
Fix some grammar in documentation of spgist and pgbench
commit : 03310dbea9746439e9f0fdedce0fa298b8c4cc76
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 20 May 2019 09:47:19 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 20 May 2019 09:47:19 +0900
Discussion: https://postgr.es/m/92961161-9b49-e42f-0a72-d5d47e0ed4de@postgrespro.ru
Author: Liudmila Mantrova
Reviewed-by: Jonathan Katz, Tom Lane, Michael Paquier
Backpatch-through: 9.4
M doc/src/sgml/ref/pgbench.sgml
M doc/src/sgml/spgist.sgml
Fix and improve SnapshotType comments.
commit : 78d6a9cbd3438969ac87b9f1aaf0f07226636ed7
author : Andres Freund <andres@anarazel.de>
date : Sun, 19 May 2019 16:17:18 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sun, 19 May 2019 16:17:18 -0700
The comment for SNAPSHOT_SELF was unfortunately explaining
SNAPSHOT_DIRTY, as reported by Sergei. Also expand a few comments, and
include a few more comments from heapam_visibility.c, so they're in an
AM independent place.
Reported-By: Sergei Kornilov
Author: Andres Freund
Discussion: https://postgr.es/m/9152241558192351@sas1-d856b3d759c7.qloud-c.yandex.net
M src/include/utils/snapshot.h
Revert "In the pg_upgrade test suite, don't write to src/test/regress."
commit : ae35e1c9d74afc3b1e7572ad60781946fdf71e95
author : Noah Misch <noah@leadboat.com>
date : Sun, 19 May 2019 15:24:42 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sun, 19 May 2019 15:24:42 -0700
This reverts commit bd1592e8570282b1650af6b8eede0016496daecd. It had
multiple defects.
Discussion: https://postgr.es/m/12717.1558304356@sss.pgh.pa.us
M src/bin/pg_upgrade/test.sh
M src/test/regress/input/largeobject.source
M src/test/regress/output/largeobject.source
M src/test/regress/output/largeobject_1.source
M src/tools/msvc/vcregress.pl
Don't to predicate lock for analyze scans, refactor scan option passing.
commit : c3b23ae457ddc8b7bfacb3c0569278615a2df2cd
author : Andres Freund <andres@anarazel.de>
date : Sun, 19 May 2019 15:10:28 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sun, 19 May 2019 15:10:28 -0700
Before this commit, when ANALYZE was run on a table and serializable
was used (either by virtue of an explicit BEGIN TRANSACTION ISOLATION
LEVEL SERIALIZABLE, or default_transaction_isolation being set to
serializable) a null pointer dereference lead to a crash.
The analyze scan doesn't need a snapshot (nor predicate locking), but
before this commit a scan only contained information about being a
bitmap or sample scan.
Refactor the option passing to the scan_begin callback to use a
bitmask instead. Alternatively we could have added a new boolean
parameter, but that seems harder to read. Even before this issue
various people (Heikki, Tom, Robert) suggested doing so.
These changes don't change the scan APIs outside of tableam. The flags
argument could be exposed, it's not necessary to fix this
problem. Also the wrapper table_beginscan* functions encapsulate most
of that complexity.
After these changes fixing the bug is trivial, just don't acquire
predicate lock for analyze style scans. That was already done for
bitmap heap scans. Add an assert that a snapshot is passed when
acquiring the predicate lock, so this kind of bug doesn't require
running with serializable.
Also add a comment about sample scans currently requiring predicate
locking the entire relation, that previously wasn't remarked upon.
Reported-By: Joe Wildish
Author: Andres Freund
Discussion:
https://postgr.es/m/4EA80A20-E9BF-49F1-9F01-5B66CAB21453@elusive.cx
https://postgr.es/m/20190411164947.nkii4gaeilt4bui7@alap3.anarazel.de
https://postgr.es/m/20190518203102.g7peu2fianukjuxm@alap3.anarazel.de
M src/backend/access/heap/heapam.c
M src/backend/access/heap/heapam_handler.c
M src/backend/access/table/tableam.c
M src/include/access/heapam.h
M src/include/access/relscan.h
M src/include/access/tableam.h
M src/test/regress/expected/vacuum.out
M src/test/regress/sql/vacuum.sql
In the pg_upgrade test suite, don't write to src/test/regress.
commit : bd1592e8570282b1650af6b8eede0016496daecd
author : Noah Misch <noah@leadboat.com>
date : Sun, 19 May 2019 14:36:44 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sun, 19 May 2019 14:36:44 -0700
When this suite runs installcheck, redirect file creations from
src/test/regress to src/bin/pg_upgrade/tmp_check/regress. This closes a
race condition in "make -j check-world". If the pg_upgrade suite wrote
to a given src/test/regress/results file in parallel with the regular
src/test/regress invocation writing it, a test failed spuriously. Even
without parallelism, in "make -k check-world", the suite finishing
second overwrote the other's regression.diffs. This revealed test
"largeobject" assuming @abs_builddir@ is getcwd(), so fix that, too.
Buildfarm client REL_10, released forty-five days ago, supports saving
regression.diffs from its new location. When an older client reports a
pg_upgradeCheck failure, it will no longer include regression.diffs.
Back-patch to 9.5, where pg_upgrade moved to src/bin.
Reviewed by Andrew Dunstan.
Discussion: https://postgr.es/m/20181224034411.GA3224776@rfd.leadboat.com
M src/bin/pg_upgrade/test.sh
M src/test/regress/input/largeobject.source
M src/test/regress/output/largeobject.source
M src/test/regress/output/largeobject_1.source
M src/tools/msvc/vcregress.pl
Improve logrotate test so that it meaningfully exercises syslogger.
commit : 9d5c22d28f8c161aa729d841aeec936c646044d4
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 19 May 2019 13:55:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 19 May 2019 13:55:39 -0400
Discussion of bug #15804 reveals that this test didn't really prove
that the syslogger child process ever launched successfully, much
less did anything. It was only checking that the expected log file
gets created, and that's done in the postmaster. Moreover, the
test assumed it could rename the log file, which is likely to fail
on Windows (cf. commit d611175e5).
Instead, use the default log file name pattern, which should result
in a new file name being chosen after 1 second, and verify that
rotation has occurred by checking for a new file name. Also add code
to test that messages actually do propagate through the syslogger.
In theory this version of the test should work on Windows, so
revert d611175e5.
Discussion: https://postgr.es/m/15804-3721117bf40fb654@postgresql.org
M src/bin/pg_ctl/t/004_logrotate.pl
Revert "postmaster: Start syslogger earlier".
commit : 833451552925d0175e1e15128e411ddef9a36996
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 19 May 2019 11:14:23 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 19 May 2019 11:14:23 -0400
This commit reverts 57431a911d3a650451d198846ad3194900666152.
While that's still a good idea in the abstract, we found out
that there are multiple crasher bugs in it on Windows builds,
making the logging_collector option unusable on Windows.
There's no time left to fix these issues before 12beta1,
so revert the patch to allow Windows beta testing to proceed.
We'll try again at some future date.
Per bug #15804 from Yulian Khodorkovskiy and additional
investigation by Michael Paquier.
Discussion: https://postgr.es/m/15804-3721117bf40fb654@postgresql.org
M src/backend/postmaster/postmaster.c
Fix declarations of couple jsonpath functions
commit : da24961e9e1d887111d17cc2dcece2e3946ca5a6
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 19 May 2019 07:45:42 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Sun, 19 May 2019 07:45:42 +0300
Make jsonb_path_query_array() and jsonb_path_query_first() use
PG_FUNCTION_ARGS macro instead of its expansion.
M src/backend/utils/adt/jsonpath_exec.c
Improve documentation for array subscription in jsonpath
commit : 87bcc02f4f739d76703feee0ff8346b98fa9b907
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Fri, 17 May 2019 05:47:53 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Fri, 17 May 2019 05:47:53 +0300
Usage of expressions and multiple ranges in jsonpath array subscription was
undocumented. This commit adds lacking documentation.
M doc/src/sgml/json.sgml
Document jsonpath .** accessor with nesting level filter
commit : e0e3dad770d3eefc4ee6cd562d9c25b61c263a6e
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Fri, 17 May 2019 05:16:31 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Fri, 17 May 2019 05:16:31 +0300
It appears that some variants of .** jsonpath accessor are undocumented. In
particular undocumented variants are:
.**{level}
.**{lower_level to upper_level}
.**{lower_level to last}
This commit adds missing documentation for them.
M doc/src/sgml/json.sgml
ANSI-ify a few straggler K&R-style function definitions.
commit : da71f98efba9aed493a178aa29f25dbca7407eaf
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 18 May 2019 20:16:50 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 18 May 2019 20:16:50 -0400
We still had a couple of these left in ancient src/port/ files.
Convert them to modern style in preparation for switching to
a version of pg_bsd_indent that doesn't cope well with K&R style.
Discussion: https://postgr.es/m/16886.1558104483@sss.pgh.pa.us
M src/port/crypt.c
M src/port/isinf.c
Make BufFileCreateTemp() ensure that temp tablespaces are set up.
commit : 93f03dad824f14f40519597e5e4a8fe7b6df858e
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 18 May 2019 13:51:16 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 18 May 2019 13:51:16 -0400
If PrepareTempTablespaces() has never been called in the current
transaction, OpenTemporaryFile() will fall back to using the default
tablespace, which is a bug if the user wanted temp files placed elsewhere.
gistInitBuildBuffers() appears to have this disease already, and it
seems like an easy trap for future coders to fall into.
We discussed other ways to close this gap, but none of them are prettier
or more reliable than just having BufFileCreateTemp do it. In particular,
having fd.c do this creates layering issues that we could do without.
Per suggestion from Melanie Plageman. Arguably this is a bug fix, but
nobody seems very excited about back-patching, so change in HEAD only.
Discussion: https://postgr.es/m/CAAKRu_YwzjuGAmmaw4-8XO=OVFGR1QhY_Pq-t3wjb9ribBJb_Q@mail.gmail.com
M src/backend/storage/file/buffile.c
docs: tighten up PG 12 release note item on 1k partitions
commit : b12db9ff5f09dc60dc05d0e208a5b28728970e55
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 18 May 2019 09:23:29 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 18 May 2019 09:23:29 -0400
M doc/src/sgml/release-12.sgml
"A void function may not return a value".
commit : d307954a7d88ed45655d9206bbe1aefc280c09c7
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 18 May 2019 00:40:39 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 18 May 2019 00:40:39 -0400
Per buildfarm.
M src/backend/access/table/tableam.c
tableam: Avoid relying on relation size to determine validity of tids.
commit : 147e3722f7e531f15ba389a4d518efe8cd0bd736
author : Andres Freund <andres@anarazel.de>
date : Fri, 17 May 2019 18:52:01 -0700
committer: Andres Freund <andres@anarazel.de>
date : Fri, 17 May 2019 18:52:01 -0700
Instead add a tableam callback to do so. To avoid adding per
validation overhead, pass a scan to tuple_tid_valid. In heap's case
we'd otherwise incurred a RelationGetNumberOfBlocks() call for each
tid - which'd have added noticable overhead to nodeTidscan.c.
Author: Andres Freund
Reviewed-By: Ashwin Agrawal
Discussion: https://postgr.es/m/20190515185447.gno2jtqxyktylyvs@alap3.anarazel.de
M src/backend/access/heap/heapam.c
M src/backend/access/heap/heapam_handler.c
M src/backend/access/table/tableam.c
M src/backend/executor/nodeTidscan.c
M src/backend/utils/adt/tid.c
M src/include/access/heapam.h
M src/include/access/tableam.h
tableam: Don't assume that every AM uses md.c style storage.
commit : 7f44ede5941499c4cee13b812dd93335f4005095
author : Andres Freund <andres@anarazel.de>
date : Fri, 17 May 2019 18:06:18 -0700
committer: Andres Freund <andres@anarazel.de>
date : Fri, 17 May 2019 18:06:18 -0700
Previously various parts of the code routed size requests through
RelationGetNumberOfBlocks[InFork]. That works if md.c is used by the
AM, but not otherwise.
Add a tableam callback to return the size of the table. As not every
AM will use postgres' BLCKSZ, have it return bytes, and have
RelationGetNumberOfBlocksInFork() round the byte size up into blocks.
To allow code outside of the AM to determine the actual relation size
map InvalidForkNumber the total size of a relation, as not every AM
might just need the postgres defined forks.
A few users of RelationGetNumberOfBlocks() ought to be converted away
from that. One case, the use of it to determine whether a tid is
valid, will be fixed in a follow up commit. Others will have to wait
for v13.
Author: Andres Freund
Discussion: https://postgr.es/m/20190423225201.3bbv6tbqzkb5w7cw@alap3.anarazel.de
M src/backend/access/heap/heapam_handler.c
M src/backend/access/table/tableamapi.c
M src/backend/storage/buffer/bufmgr.c
M src/include/access/tableam.h
Restructure creation of run-time pruning steps.
commit : 6630ccad7a25cad32e2d1a6833fb971602cb67fe
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 May 2019 19:44:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 17 May 2019 19:44:19 -0400
Previously, gen_partprune_steps() always built executor pruning steps
using all suitable clauses, including those containing PARAM_EXEC
Params. This meant that the pruning steps were only completely safe
for executor run-time (scan start) pruning. To prune at executor
startup, we had to ignore the steps involving exec Params. But this
doesn't really work in general, since there may be logic changes
needed as well --- for example, pruning according to the last operator's
btree strategy is the wrong thing if we're not applying that operator.
The rules embodied in gen_partprune_steps() and its minions are
sufficiently complicated that tracking their incremental effects in
other logic seems quite impractical.
Short of a complete redesign, the only safe fix seems to be to run
gen_partprune_steps() twice, once to create executor startup pruning
steps and then again for run-time pruning steps. We can save a few
cycles however by noting during the first scan whether we rejected
any clauses because they involved exec Params --- if not, we don't
need to do the second scan.
In support of this, refactor the internal APIs in partprune.c to make
more use of passing information in the GeneratePruningStepsContext
struct, rather than as separate arguments.
This is, I hope, the last piece of our response to a bug report from
Alan Jackson. Back-patch to v11 where this code came in.
Discussion: https://postgr.es/m/FAD28A83-AC73-489E-A058-2681FA31D648@tvsquared.com
M src/backend/executor/execPartition.c
M src/backend/nodes/copyfuncs.c
M src/backend/nodes/outfuncs.c
M src/backend/nodes/readfuncs.c
M src/backend/partitioning/partprune.c
M src/include/executor/execPartition.h
M src/include/nodes/plannodes.h
M src/include/partitioning/partprune.h
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql
docs: split out sort-skip partition item in PG 12 release notes
commit : 05685897f07e7ae5684f0247157faad1f782f889
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 17 May 2019 11:31:49 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 17 May 2019 11:31:49 -0400
Discussion: https://postgr.es/m/0cf10a27-c6a0-de4a-cd20-ab7493ea7422@lab.ntt.co.jp
M doc/src/sgml/release-12.sgml
Fix regression test outputs
commit : 6ba500cae6f57acf8f392d9e1671640f7c9d43b3
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 17 May 2019 09:40:02 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 17 May 2019 09:40:02 +0900
75445c1 has caused various failures in tests across the tree after
updating some error messages, so fix the newly-expected output.
Author: Michael Paquier
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/8332.1558048838@sss.pgh.pa.us
M contrib/citext/expected/citext.out
M contrib/citext/expected/citext_1.out
M src/test/regress/expected/copy2.out
M src/test/regress/expected/create_table.out
M src/test/regress/expected/jsonb_jsonpath.out
M src/test/regress/expected/jsonpath.out
M src/test/regress/expected/publication.out
M src/test/regress/expected/regex.out
M src/test/regress/expected/strings.out
M src/test/regress/expected/subscription.out
M src/test/regress/output/copy.source
Fix typos in documentatoin of GSSAPI encryption
commit : 41998f90ce66425ca6071ac5e170a19bb1498414
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 17 May 2019 08:22:28 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 17 May 2019 08:22:28 +0900
Author: Daniel Gustafsson
Discussion: https://postgr.es/m/5520EDD8-7AC7-4307-8171-400DD1D84FDC@yesql.se
M doc/src/sgml/protocol.sgml
M doc/src/sgml/runtime.sgml
More message style fixes
commit : 75445c1515fffa581585f1b72e5b5314c1c395ce
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 16 May 2019 18:50:56 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 16 May 2019 18:50:56 -0400
Discussion: https://postgr.es/m/20190515183005.GA26486@alvherre.pgsql
M src/backend/commands/copy.c
M src/backend/commands/publicationcmds.c
M src/backend/commands/subscriptioncmds.c
M src/backend/commands/tablecmds.c
M src/backend/parser/analyze.c
M src/backend/postmaster/postmaster.c
M src/backend/replication/walsender.c
M src/backend/utils/adt/jsonpath.c
M src/backend/utils/adt/jsonpath_exec.c
M src/backend/utils/adt/jsonpath_scan.l
M src/backend/utils/adt/pg_locale.c
M src/backend/utils/adt/regexp.c
Remove extra nbtree half-dead internal page check.
commit : 3f58cc6dd8fc821992da7ed8099d283b014fc2dc
author : Peter Geoghegan <pg@bowt.ie>
date : Thu, 16 May 2019 15:11:58 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Thu, 16 May 2019 15:11:58 -0700
It's not safe for nbtree VACUUM to attempt to delete a target page whose
right sibling is already half-dead, since that would fail the
cross-check when VACUUM attempts to re-find a downlink to the right
sibling in the parent page. Logic to prevent this from happening was
added by commit 8da31837803, which addressed a bug in the overhaul of
page deletion that went into PostgreSQL 9.4 (commit efada2b8e92).
VACUUM was made to check the right sibling page, and back off when it
happened to be half-dead already.
However, it is only truly necessary to do the right sibling check on the
leaf level, since that transitively determines if the deletion target's
parent's right sibling page is itself undergoing deletion. Remove the
internal page level check, and add a comment explaining why the leaf
level check alone suffices.
The extra check is also unnecessary due to the fact that internal pages
that are marked half-dead are generally considered corrupt. Commit
efada2b8e92 established the principle that there should never be
half-dead internal pages (internal pages pending deletion are possible,
but that status is never directly represented in the internal page).
VACUUM will complain about corruption when it encounters half-dead
internal pages, so VACUUM is bound to raise an error one way or another
when an nbtree index has a half-dead internal page (contrib/amcheck will
also report that the page is corrupt).
It's possible that a pg_upgrade'd 9.3 database will still have half-dead
internal pages, so it may seem like there is an argument for leaving the
check in place to reliably get a cleaner error message that advises the
user to REINDEX. However, leaf pages are also deleted in the first
phase of deletion prior to PostgreSQL 9.4, so I believe we won't even
attempt to re-find the parent page anyway (we won't have the fully
deleted leaf page as the right sibling of our target page, so we won't
even try to find a downlink for it).
Discussion: https://postgr.es/m/CAH2-Wzm_ntmqJjWLRyKzimFmFvk+BnVAvUpaA4s1h9Ja58woaQ@mail.gmail.com
M src/backend/access/nbtree/README
M src/backend/access/nbtree/nbtpage.c
Fix bogus logic for combining range-partitioned columns during pruning.
commit : 3922f10646fc79264228ea3f6a7343cc3f8f528a
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 16 May 2019 16:25:43 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 16 May 2019 16:25:43 -0400
gen_prune_steps_from_opexps's notion of how to do this was overly
complicated and underly correct.
Per discussion of a report from Alan Jackson (though this fixes only one
aspect of that problem). Back-patch to v11 where this code came in.
Amit Langote
Discussion: https://postgr.es/m/FAD28A83-AC73-489E-A058-2681FA31D648@tvsquared.com
M src/backend/partitioning/partprune.c
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql
Fix partition pruning to treat stable comparison operators properly.
commit : 4b1fcb43d070ba8b34ea01d5a657630d76e4b33f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 16 May 2019 11:58:21 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 16 May 2019 11:58:21 -0400
Cross-type comparison operators in a btree or hash opclass might be
only stable not immutable (this is true of timestamp vs. timestamptz
for example). partprune.c ignored this possibility and would perform
plan-time pruning with them anyway, possibly leading to wrong answers
if the environment changed between planning and execution.
To fix, teach gen_partprune_steps() to do things differently when
creating plan-time pruning steps vs. run-time pruning steps.
analyze_partkey_exprs() also needs an extra check, which is rather
annoying but now is not the time to restructure things enough to
avoid that.
While at it, simplify the logic for the plan-time case a little
by insisting that the comparison value be a Const and nothing else.
This relies on the assumption that eval_const_expressions will have
reduced any immutable expression to a Const; which is not quite
100% true, but certainly any case that comes up often enough to be
interesting should have simplification logic there.
Also improve a bunch of inadequate/obsolete/wrong comments.
Per discussion of a report from Alan Jackson (though this fixes only one
aspect of that problem). Back-patch to v11 where this code came in.
David Rowley, with some further hacking by me
Discussion: https://postgr.es/m/FAD28A83-AC73-489E-A058-2681FA31D648@tvsquared.com
M src/backend/partitioning/partprune.c
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql
Remove obsolete nbtree insertion comment.
commit : 489e431ba56b10f5736fb54a045ca40880f11bbc
author : Peter Geoghegan <pg@bowt.ie>
date : Wed, 15 May 2019 16:53:11 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Wed, 15 May 2019 16:53:11 -0700
Remove a Berkeley-era comment above _bt_insertonpg() that admonishes the
reader to grok Lehman and Yao's paper before making any changes. This
made a certain amount of sense back when _bt_insertonpg() was
responsible for most of the things that are now spread across
_bt_insertonpg(), _bt_findinsertloc(), _bt_insert_parent(), and
_bt_split(), but it doesn't work like that anymore.
I believe that this comment alludes to the need to "couple" or "crab"
buffer locks as we ascend the tree as page splits cascade upwards. The
nbtree README already explains this in detail, which seems sufficient.
Besides, the changes to page splits made by commit 40dae7ec537 altered
the exact details of how buffer locks are retained during splits; Lehman
and Yao's original algorithm seems to release the lock on the left child
page/buffer slightly earlier than _bt_insertonpg()/_bt_insert_parent()
can.
M src/backend/access/nbtree/nbtinsert.c
Remove no-longer-used typedef.
commit : 8a0f0ad54047c8dc1430e521e2dc90f2cd138a9d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 15 May 2019 17:26:52 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 15 May 2019 17:26:52 -0400
struct ClonedConstraint is no longer needed, so delete it.
Discussion: https://postgr.es/m/18102.1557947143@sss.pgh.pa.us
M src/include/catalog/pg_constraint.h
Reverse order of newitem nbtree candidate splits.
commit : 7505da2f459776a397177f7d591991f5591c2812
author : Peter Geoghegan <pg@bowt.ie>
date : Wed, 15 May 2019 12:22:07 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Wed, 15 May 2019 12:22:07 -0700
Commit fab25024, which taught nbtree to choose candidate split points
more carefully, had _bt_findsplitloc() record all possible split points
in an initial pass over a page that is about to be split. The order
that candidate split points were processed and stored in was assumed to
match the offset number order of split points on an imaginary version of
the page that contains the same items as the original, but also fits
newitem (the item that provoked the split precisely because it didn't
fit).
However, the order of split points in the final array was not quite what
was expected: the split point that makes newitem the firstright item
came after the split point that makes newitem the lastleft item -- not
before. As a result, _bt_findsplitloc() could get confused about the
leftmost and rightmost tuples among all possible split points recorded
for the page. This seems to have no appreciable impact on the quality
of the final split point chosen by _bt_findsplitloc(), but it's still
wrong.
To fix, switch the order in which newitem candidate splits are recorded
in. This also makes it possible to describe candidate split points in
terms of which pair of adjoining tuples enclose the split point within
_bt_findsplitloc(), making it clearer why it's generally safe for
_bt_split() to expect lastleft and firstright tuples.
M src/backend/access/nbtree/nbtsplitloc.c
docs: properly indent PG 12 release notes
commit : a429164ef31fc6899cef4d5e4f3f2ce8fc33aa27
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 15 May 2019 12:44:59 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 15 May 2019 12:44:59 -0400
M doc/src/sgml/release-12.sgml
Handle table_complete_speculative's succeeded argument as documented.
commit : aa4b8c61d2cd57b53be03defb04d59b232a0e150
author : Andres Freund <andres@anarazel.de>
date : Tue, 14 May 2019 12:11:26 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 14 May 2019 12:11:26 -0700
For some reason both callsite and the implementation for heapam had
the meaning inverted (i.e. succeeded == true was passed in case of
conflict). That's confusing.
I (Andres) briefly pondered whether it'd be better to rename
table_complete_speculative's argument to 'bool specConflict' or such,
but decided not to. The 'complete' in the function name for me makes
`succeeded` sound a bit better.
Reported-By: Ashwin Agrawal, Melanie Plageman, Heikki Linnakangas
Discussion:
https://postgr.es/m/CALfoeitk7-TACwYv3hCw45FNPjkA86RfXg4iQ5kAOPhR+F1Y4w@mail.gmail.com
https://postgr.es/m/97673451-339f-b21e-a781-998d06b1067c@iki.fi
M src/backend/access/heap/heapam_handler.c
M src/backend/executor/nodeModifyTable.c
Add isolation test for INSERT ON CONFLICT speculative insertion failure.
commit : 08e2edc0767ab6e619970f165cb34d4673105f23
author : Andres Freund <andres@anarazel.de>
date : Tue, 14 May 2019 11:45:40 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 14 May 2019 11:45:40 -0700
This path previously was not reliably covered. There was some
heuristic coverage via insert-conflict-toast.spec, but that test is
not deterministic, and only tested for a somewhat specific bug.
Backpatch, as this is a complicated and otherwise untested code
path. Unfortunately 9.5 cannot handle two waiting sessions, and thus
cannot execute this test.
Triggered by a conversion with Melanie Plageman.
Author: Andres Freund
Discussion: https://postgr.es/m/CAAKRu_a7hbyrk=wveHYhr4LbcRnRCG=yPUVoQYB9YO1CdUBE9Q@mail.gmail.com
Backpatch: 9.5-
A src/test/isolation/expected/insert-conflict-specconflict.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/insert-conflict-specconflict.spec
Fix "make clean" to clean out junk files left behind after ssl tests.
commit : 6d2fba3189608186d1a196a595f21760412ec5e8
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 May 2019 14:28:33 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 May 2019 14:28:33 -0400
We .gitignore'd this junk, but we didn't actually remove it.
M src/test/ssl/Makefile
Move logging.h and logging.c from src/fe_utils/ to src/common/.
commit : fc9a62af3f87f4bec1e8c904ea99ae50f3c881ef
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 May 2019 14:19:49 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 May 2019 14:19:49 -0400
The original placement of this module in src/fe_utils/ is ill-considered,
because several src/common/ modules have dependencies on it, meaning that
libpgcommon and libpgfeutils now have mutual dependencies. That makes it
pointless to have distinct libraries at all. The intended design is that
libpgcommon is lower-level than libpgfeutils, so only dependencies from
the latter to the former are acceptable.
We already have the precedent that fe_memutils and a couple of other
modules in src/common/ are frontend-only, so it's not stretching anything
out of whack to treat logging.c as a frontend-only module in src/common/.
To the extent that such modules help provide a common frontend/backend
environment for the rest of common/ to use, it's a reasonable design.
(logging.c does not yet provide an ereport() emulation, but one can
dream.)
Hence, move these files over, and revert basically all of the build-system
changes made by commit cc8d41511. There are no places that need to grow
new dependencies on libpgcommon, further reinforcing the idea that this
is the right solution.
Discussion: https://postgr.es/m/a912ffff-f6e4-778a-c86a-cf5c47a12933@2ndquadrant.com
M src/bin/initdb/initdb.c
M src/bin/pg_archivecleanup/Makefile
M src/bin/pg_archivecleanup/pg_archivecleanup.c
M src/bin/pg_basebackup/pg_basebackup.c
M src/bin/pg_basebackup/pg_receivewal.c
M src/bin/pg_basebackup/pg_recvlogical.c
M src/bin/pg_basebackup/receivelog.c
M src/bin/pg_basebackup/streamutil.c
M src/bin/pg_checksums/Makefile
M src/bin/pg_checksums/pg_checksums.c
M src/bin/pg_controldata/Makefile
M src/bin/pg_controldata/pg_controldata.c
M src/bin/pg_ctl/Makefile
M src/bin/pg_ctl/pg_ctl.c
M src/bin/pg_dump/common.c
M src/bin/pg_dump/pg_backup_archiver.c
M src/bin/pg_dump/pg_backup_custom.c
M src/bin/pg_dump/pg_backup_db.c
M src/bin/pg_dump/pg_backup_utils.h
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump_sort.c
M src/bin/pg_dump/pg_dumpall.c
M src/bin/pg_dump/pg_restore.c
M src/bin/pg_resetwal/Makefile
M src/bin/pg_resetwal/pg_resetwal.c
M src/bin/pg_rewind/Makefile
M src/bin/pg_rewind/datapagemap.c
M src/bin/pg_rewind/pg_rewind.h
M src/bin/pg_test_fsync/Makefile
M src/bin/pg_test_fsync/pg_test_fsync.c
M src/bin/pg_upgrade/pg_upgrade.c
M src/bin/pg_waldump/Makefile
M src/bin/pg_waldump/pg_waldump.c
M src/bin/pgbench/pgbench.c
M src/bin/psql/command.c
M src/bin/psql/common.c
M src/bin/psql/copy.c
M src/bin/psql/crosstabview.c
M src/bin/psql/describe.c
M src/bin/psql/help.c
M src/bin/psql/input.c
M src/bin/psql/large_obj.c
M src/bin/psql/mainloop.c
M src/bin/psql/psqlscanslash.l
M src/bin/psql/startup.c
M src/bin/psql/variables.c
M src/bin/scripts/clusterdb.c
M src/bin/scripts/common.c
M src/bin/scripts/createdb.c
M src/bin/scripts/createuser.c
M src/bin/scripts/dropdb.c
M src/bin/scripts/dropuser.c
M src/bin/scripts/pg_isready.c
M src/bin/scripts/reindexdb.c
M src/bin/scripts/vacuumdb.c
M src/common/Makefile
M src/common/controldata_utils.c
M src/common/file_utils.c
R092 src/fe_utils/logging.c src/common/logging.c
M src/common/pgfnames.c
M src/common/restricted_token.c
M src/common/rmtree.c
M src/fe_utils/Makefile
M src/fe_utils/psqlscan.l
R092 src/include/fe_utils/logging.h src/include/common/logging.h
M src/interfaces/ecpg/test/Makefile
M src/nls-global.mk
M src/test/isolation/Makefile
M src/test/regress/GNUmakefile
M src/test/regress/pg_regress.c
M src/tools/msvc/Mkvcbuild.pm
docs: Indent listitem tags in PG 12 release notes
commit : b71dad22ce8a645a47c01e544f640f35b91bfbd3
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 14 May 2019 13:32:03 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 14 May 2019 13:32:03 -0400
M doc/src/sgml/release-12.sgml
Remove pg_rewind's private logging.h/logging.c files.
commit : 53ddefbaf8a0493d2c1fa0b18bfaba72da556985
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 May 2019 13:11:23 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 May 2019 13:11:23 -0400
The existence of these files became rather confusing with the
introduction of a widely-known logging.h header in commit cc8d41511.
(Indeed, there's already some duplicative #includes here, perhaps
betraying such confusion.) The only thing left in them, after that
commit, is a progress-reporting function that's neither general-purpose
nor tied in any way to other logging infrastructure. Hence, let's just
move that function to pg_rewind.c, and get rid of the separate files.
Discussion: https://postgr.es/m/3971.1557787914@sss.pgh.pa.us
M src/bin/pg_rewind/Makefile
M src/bin/pg_rewind/copy_fetch.c
M src/bin/pg_rewind/file_ops.c
M src/bin/pg_rewind/filemap.c
M src/bin/pg_rewind/libpq_fetch.c
D src/bin/pg_rewind/logging.c
D src/bin/pg_rewind/logging.h
M src/bin/pg_rewind/nls.mk
M src/bin/pg_rewind/parsexlog.c
M src/bin/pg_rewind/pg_rewind.c
M src/bin/pg_rewind/pg_rewind.h
M src/bin/pg_rewind/timeline.c
Fix SQL-style substring() to have spec-compliant greediness behavior.
commit : 7c850320d8cfa5503ecec61c2559661b924f7595
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 May 2019 11:27:31 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 May 2019 11:27:31 -0400
SQL's regular-expression substring() function is defined to have a
pattern argument that's separated into three subpatterns by escape-
double-quote markers; the function result is the part of the input
matching the second subpattern. The standard makes it clear that
if there is ambiguity about how to match the input to the subpatterns,
the first and third subpatterns should be taken to match the smallest
possible amount of text (i.e., they're "non greedy", in the terms of
our regex code). We were not doing it that way: the first subpattern
would eat the largest possible amount of text, causing the function
result to be shorter than what the spec requires.
Fix that by attaching explicit greediness quantifiers to the
subpatterns. (This depends on the regex fix in commit 8a29ed053;
before that, this didn't reliably change the regex engine's behavior.)
Also, by adding parentheses around each subpattern, we ensure that
"|" (OR) in the subpatterns behave sanely. Previously, "|" in the
first or third subpatterns didn't work.
This patch also makes the function throw error if you write more than
two escape-double-quote markers, and do something sane if you write
just one, and document that behavior. Previously, an odd number of
markers led to a confusing complaint about unbalanced parentheses,
while extra pairs of markers were just ignored. (Note that the spec
requires exactly two markers, but we've historically allowed there
to be none, and this patch preserves the old behavior for that case.)
In passing, adjust some substring() test cases that didn't really
prove what they said they were testing for: they used patterns
that didn't match the data string, so that the output would be
NULL whether or not the function was really strict.
Although this is certainly a bug fix, changing the behavior in back
branches seems undesirable: applications could perhaps be depending on
the old behavior, since it's not obviously wrong unless you read the
spec very closely. Hence, no back-patch.
Discussion: https://postgr.es/m/5bb27a41-350d-37bf-901e-9d26f5592dd0@charter.net
M doc/src/sgml/func.sgml
M src/backend/utils/adt/regexp.c
M src/test/regress/expected/strings.out
M src/test/regress/sql/strings.sql
In bootstrap mode, use default signal handling for SIGINT etc.
commit : fb489e4b3195fc33cccc0fd308e5a0ab502cf199
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 May 2019 10:22:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 14 May 2019 10:22:28 -0400
Previously, the code pointed the standard process-termination signals
to postgres.c's die(). That would typically result in an attempt to
execute a transaction abort, which is not possible in bootstrap mode,
leading to PANIC. This choice seems to be a leftover from an old code
structure in which the same signal-assignment code was used for many
sorts of auxiliary processes, including interactive standalone
backends. It's not very sensible for bootstrap mode, which has no
interest in either interactivity or continuing after an error. We can
get better behavior with less effort by just letting normal process
termination happen, after which the parent initdb process will clean up.
This is basically cosmetic in any case, since initdb will react the
same way whether bootstrap dies on a signal or abort(). Given the
lack of previous complaints, I don't feel a need to back-patch,
even though the behavior is old.
Discussion: https://postgr.es/m/3850b11a.5121.16aaf827e4a.Coremail.thunder1@126.com
M src/backend/bootstrap/bootstrap.c
Update SQL features/conformance information to SQL:2016
commit : 037165ca95d854e04c0c28cfa85f1515bd852892
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 14 May 2019 14:56:58 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 14 May 2019 14:56:58 +0200
M doc/src/sgml/features.sgml
M src/backend/catalog/information_schema.sql
M src/backend/catalog/sql_features.txt
M src/include/catalog/catversion.h
Update information_schema for SQL:2016
commit : eb3a1376c98a1d220354b468f4b09e4a1dca909a
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 14 May 2019 15:15:05 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 14 May 2019 15:15:05 +0200
This is mainly a light renumbering to match the sections in the
standard.
M src/backend/catalog/information_schema.sql
Update SQL keywords list to SQL:2016
commit : c29ba98189190288c2251c6073c13c6234479e5c
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 14 May 2019 09:56:40 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 14 May 2019 09:56:40 +0200
Per previous convention (see
ace397e9d24eddc56e7dffa921f506117b602d78), drop SQL:2008 and only keep
the latest two standards and SQL-92.
Note: SQL:2016-2 lists a large number of non-reserved keywords that
are really just information_schema column names related to new
features. Those kinds of thing have not previously been listed as
keywords, and this was apparently done here by mistake, since these
keywords have been removed again in post-2016 working drafts. So in
order to avoid bloating the keywords table unnecessarily, I have
omitted these erroneous keywords here.
M doc/src/sgml/generate-keywords-table.pl
R090 doc/src/sgml/keywords/sql2008-02-nonreserved.txt doc/src/sgml/keywords/sql2016-02-nonreserved.txt
R082 doc/src/sgml/keywords/sql2008-02-reserved.txt doc/src/sgml/keywords/sql2016-02-reserved.txt
R100 doc/src/sgml/keywords/sql2008-09-nonreserved.txt doc/src/sgml/keywords/sql2016-09-nonreserved.txt
R100 doc/src/sgml/keywords/sql2008-09-reserved.txt doc/src/sgml/keywords/sql2016-09-reserved.txt
R093 doc/src/sgml/keywords/sql2008-14-nonreserved.txt doc/src/sgml/keywords/sql2016-14-nonreserved.txt
R100 doc/src/sgml/keywords/sql2008-14-reserved.txt doc/src/sgml/keywords/sql2016-14-reserved.txt
docs: update partition item in PG 12 release notes
commit : 356c83795aaa39cfd9bca588bfe4f0196710962e
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 14 May 2019 09:17:08 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 14 May 2019 09:17:08 -0400
Reported-by: Amit Langote
Discussion: https://postgr.es/m/b7954643-41ef-a174-479d-1f8d4834f40a@lab.ntt.co.jp
M doc/src/sgml/release-12.sgml
docs: fix duplicate wording in PG 12 release notes
commit : 34d40becfa7a5c7343d0079f181597d7e06122e1
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 14 May 2019 09:06:03 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 14 May 2019 09:06:03 -0400
Reported-by: nickb@imap.cc
Discussion: https://postgr.es/m/6b3414e1-fcef-4ad9-b123-b3ab3702d3db@www.fastmail.com
M doc/src/sgml/release-12.sgml
Detect internal GiST page splits correctly during index build.
commit : 22251686f07f70527aecda22ab5402986884f6f5
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 14 May 2019 13:18:44 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 14 May 2019 13:18:44 +0300
As we descend the GiST tree during insertion, we modify any downlinks on
the way down to include the new tuple we're about to insert (if they don't
cover it already). Modifying an existing downlink might cause an internal
page to split, if the new downlink tuple is larger than the old one. If
that happens, we need to back up to the parent and re-choose a page to
insert to. We used to detect that situation, thanks to the NSN-LSN
interlock normally used to detect concurrent page splits, but that got
broken by commit 9155580fd5. With that commit, we now use a dummy constant
LSN value for every page during index build, so the LSN-NSN interlock no
longer works. I thought that was OK because there can't be any other
backends modifying the index during index build, but missed that the
insertion itself can modify the page we're inserting to. The consequence
was that we would sometimes insert the new tuple to an incorrect page, one
whose downlink doesn't cover the new tuple.
To fix, add a flag to the stack that keeps track of the state while
descending tree, to indicate that a page was split, and that we need to
retry the descend from the parent.
Thomas Munro first reported that the contrib/intarray regression test was
failing occasionally on the buildfarm after commit 9155580fd5. The failure
was intermittent, because the gistchoose() function is not deterministic,
and would only occasionally create the right circumstances for this bug to
cause the failure.
Patch by Anastasia Lubennikova, with some changes by me to make it work
correctly also when the internal page split also causes the "grandparent"
to be split.
Discussion: https://www.postgresql.org/message-id/CA%2BhUKGJRzLo7tZExWfSbwM3XuK7aAK7FhdBV0FLkbUG%2BW0v0zg%40mail.gmail.com
M src/backend/access/gist/gist.c
M src/include/access/gist_private.h
Fix comment on when HOT update is possible.
commit : e95d550bbbe21f51d329fbae84cbac3545a9e650
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 14 May 2019 13:06:28 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Tue, 14 May 2019 13:06:28 +0300
The conditions listed in this comment have changed several times, and at
some point the thing that the "if so" referred to was negated.
The text was OK up to 9.6. It was differently wrong in v10, v11 and
master, so fix in all those versions.
M src/backend/access/heap/heapam.c
Fix typo.
commit : 7d9eca59cf958eb8c8ff47c40003392681a9ce68
author : Etsuro Fujita <efujita@postgresql.org>
date : Tue, 14 May 2019 16:05:37 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Tue, 14 May 2019 16:05:37 +0900
M src/backend/utils/misc/postgresql.conf.sample
doc: Update OID item in PG 12 release notes
commit : 0b62f0f2552d895301fdae56aa839c1eaae24a3a
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 13 May 2019 22:55:38 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 13 May 2019 22:55:38 -0400
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20190513174759.GE23251@telsasoft.com
M doc/src/sgml/release-12.sgml
doc: improve wording of PG 12 releaase note partition item
commit : f4125278e3c92d8cdd83c77d0b54f468ee81c750
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 13 May 2019 22:38:50 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 13 May 2019 22:38:50 -0400
Reported-by: Amit Langote
Discussion: https://postgr.es/m/d5267ae5-bd4a-3e96-c21b-56bfa9fec7e8@lab.ntt.co.jp
M doc/src/sgml/release-12.sgml
doc: properly attibute PG 12 pgbench release note item
commit : 5d971565a7993ba8dcd06d34d1387af48fdbd034
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 13 May 2019 22:21:32 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 13 May 2019 22:21:32 -0400
Reported-by: Fabien COELHO
Discussion: https://postgr.es/m/alpine.DEB.2.21.1905130839140.13487@lancre
M doc/src/sgml/release-12.sgml
Fix duplicated words in comments
commit : 7e19929ea29668f3d01280262e407b93042c959a
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 14 May 2019 09:37:35 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 14 May 2019 09:37:35 +0900
Author: Stephen Amell
Discussion: https://postgr.es/m/539fa271-21b3-777e-a468-d96cffe9c768@gmail.com
M src/backend/executor/execExpr.c
M src/backend/replication/logical/reorderbuffer.c
M src/include/c.h
M src/include/jit/llvmjit_emit.h
M src/include/nodes/execnodes.h
M src/include/replication/logical.h
Standardize ItemIdData terminology.
commit : ae7291acbc5ae4c3751615177fc256f9f3399403
author : Peter Geoghegan <pg@bowt.ie>
date : Mon, 13 May 2019 15:53:39 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Mon, 13 May 2019 15:53:39 -0700
The term "item pointer" should not be used to refer to ItemIdData
variables, since that is needlessly ambiguous. Only
ItemPointerData/ItemPointer variables should be called item pointers.
To fix, establish the convention that ItemIdData variables should always
be referred to either as "item identifiers" or "line pointers". The
term "item identifier" already predominates in docs and translatable
messages, and so should be the preferred alternative there.
Discussion: https://postgr.es/m/CAH2-Wz=c=MZQjUzde3o9+2PLAPuHTpVZPPdYxN=E4ndQ2--8ew@mail.gmail.com
M contrib/amcheck/verify_nbtree.c
M src/backend/access/heap/README.HOT
M src/backend/access/heap/heapam.c
M src/backend/access/heap/heapam_handler.c
M src/backend/access/heap/pruneheap.c
M src/backend/access/heap/vacuumlazy.c
M src/backend/access/index/indexam.c
M src/backend/access/nbtree/nbtinsert.c
M src/backend/access/spgist/spgvacuum.c
M src/backend/storage/page/bufpage.c
M src/include/access/htup_details.h
M src/include/access/itup.h
M src/include/storage/bufpage.h
M src/include/storage/itemid.h
Doc: Refer to line pointers as item identifiers.
commit : 08ca9d7feca890e97f77ef1fde02d7542a54ac5e
author : Peter Geoghegan <pg@bowt.ie>
date : Mon, 13 May 2019 15:39:06 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Mon, 13 May 2019 15:39:06 -0700
An upcoming HEAD-only patch will standardize the terminology around
ItemIdData variables/line pointers, ending the practice of referring to
them as "item pointers". Make the "Database Page Layout" docs
consistent with the new policy. The term "item identifier" is already
used in the same section, so stick with that.
Discussion: https://postgr.es/m/CAH2-Wz=c=MZQjUzde3o9+2PLAPuHTpVZPPdYxN=E4ndQ2--8ew@mail.gmail.com
Backpatch: All supported branches.
M doc/src/sgml/storage.sgml
Fix logical replication's ideas about which type OIDs are built-in.
commit : 32ebb35128c3d16b64039f6d6774afd96a3d91b9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 May 2019 17:23:00 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 May 2019 17:23:00 -0400
Only hand-assigned type OIDs should be presumed to match across different
PG servers; those assigned during genbki.pl or during initdb are likely
to change due to addition or removal of unrelated objects.
This means that the cutoff should be FirstGenbkiObjectId (in HEAD)
or FirstBootstrapObjectId (before that), not FirstNormalObjectId.
Compare postgres_fdw's is_builtin() test.
It's likely that this error has no observable consequence in a
normally-functioning system, since ATM the only affected type OIDs are
system catalog rowtypes and information_schema types, which would not
typically be interesting for logical replication. But you could
probably break it if you tried hard, so back-patch.
Discussion: https://postgr.es/m/15150.1557257111@sss.pgh.pa.us
M src/backend/replication/logical/relation.c
M src/backend/replication/pgoutput/pgoutput.c
Improve commentary about hack in is_publishable_class().
commit : e34ee993fbc38c8538f9342c5961e5f61fd45180
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 May 2019 17:05:48 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 May 2019 17:05:48 -0400
The FirstNormalObjectId test here is a kluge that needs to go away,
but the only substitute we can think of is to add a column to pg_class,
which will take more work than can be handled right now. Add some
commentary in the meanwhile.
Discussion: https://postgr.es/m/15150.1557257111@sss.pgh.pa.us
M src/backend/catalog/pg_publication.c
Don't leave behind junk nbtree pages during split.
commit : 9b42e713761a43e9ade3965285f077e2ba25bbb7
author : Peter Geoghegan <pg@bowt.ie>
date : Mon, 13 May 2019 10:27:59 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Mon, 13 May 2019 10:27:59 -0700
Commit 8fa30f906be reduced the elevel of a number of "can't happen"
_bt_split() errors from PANIC to ERROR. At the same time, the new right
page buffer for the split could continue to be acquired well before the
critical section. This was possible because it was relatively
straightforward to make sure that _bt_split() could not throw an error,
with a few specific exceptions. The exceptional cases were safe because
they involved specific, well understood errors, making it possible to
consistently zero the right page before actually raising an error using
elog(). There was no danger of leaving around a junk page, provided
_bt_split() stuck to this coding rule.
Commit 8224de4f, which introduced INCLUDE indexes, added code to make
_bt_split() truncate away non-key attributes. This happened at a point
that broke the rule around zeroing the right page in _bt_split(). If
truncation failed (perhaps due to palloc() failure), that would result
in an errant right page buffer with junk contents. This could confuse
VACUUM when it attempted to delete the page, and should be avoided on
general principle.
To fix, reorganize _bt_split() so that truncation occurs before the new
right page buffer is even acquired. A junk page/buffer will not be left
behind if _bt_nonkey_truncate()/_bt_truncate() raise an error.
Discussion: https://postgr.es/m/CAH2-WzkcWT_-NH7EeL=Az4efg0KCV+wArygW8zKB=+HoP=VWMw@mail.gmail.com
Backpatch: 11-, where INCLUDE indexes were introduced.
M src/backend/access/nbtree/nbtinsert.c
Improve comment for att_isnull.
commit : 221b377f09a30dd7c74c26c8c1db439afcc59141
author : Robert Haas <rhaas@postgresql.org>
date : Mon, 13 May 2019 13:13:24 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Mon, 13 May 2019 13:13:24 -0400
The comment implies that a 1 in the null bitmap indicates a null value,
but actually a 0 in the null bitmap indicates a null value. Try to
be more clear.
Patch by me; proposed wording reviewed by Alvaro Herrera and Tom Lane.
Discussion: http://postgr.es/m/CA+TgmobHOP8r6cG+UnsDFMrS30-m=jRrCBhgw-nFkn0k9QnFsg@mail.gmail.com
M src/include/access/tupmacs.h
Fix misuse of an integer as a bool.
commit : ddf927fb13471bec0cc76794eaf552df8a1178fb
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 May 2019 10:53:19 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Mon, 13 May 2019 10:53:19 -0400
pgtls_read_pending is declared to return bool, but what the underlying
SSL_pending function returns is a count of available bytes.
This is actually somewhat harmless if we're using C99 bools, but in
the back branches it's a live bug: if the available-bytes count happened
to be a multiple of 256, it would get converted to a zero char value.
On machines where char is signed, counts of 128 and up could misbehave
as well. The net effect is that when using SSL, libpq might block
waiting for data even though some has already been received.
Broken by careless refactoring in commit 4e86f1b16, so back-patch
to 9.5 where that came in.
Per bug #15802 from David Binderman.
Discussion: https://postgr.es/m/15802-f0911a97f0346526@postgresql.org
M src/interfaces/libpq/fe-misc.c
M src/interfaces/libpq/fe-secure-openssl.c
postgres_fdw: Fix typo in comment.
commit : cc866941ad4583f07e5637c145f6f6ee8a573e11
author : Etsuro Fujita <efujita@postgresql.org>
date : Mon, 13 May 2019 17:30:35 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Mon, 13 May 2019 17:30:35 +0900
M contrib/postgres_fdw/postgres_fdw.c
doc: PG 12 release notes: normalize attribution names
commit : f86b0c3c465319b80d71db7d7a9de636950e104a
author : Bruce Momjian <bruce@momjian.us>
date : Sun, 12 May 2019 23:54:02 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sun, 12 May 2019 23:54:02 -0400
Reported-by: David Rowley
Discussion: https://postgr.es/m/CAKJS1f-ktEhmQ2zJQ1L1niuJ9KB8WPA-bE-AhGiFsSO6QASB_w@mail.gmail.com
M doc/src/sgml/release-12.sgml
doc: adjust PG 12 release note sections
commit : a6927996be59ac329d65d41cf058d0b1b0978eeb
author : Bruce Momjian <bruce@momjian.us>
date : Sun, 12 May 2019 23:41:53 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sun, 12 May 2019 23:41:53 -0400
Tighten section designations.
M doc/src/sgml/release-12.sgml
docs: fix typo in mention of MSVC
commit : fefb6a75386b72a40f697523953eafc7cb1c7a5b
author : Bruce Momjian <bruce@momjian.us>
date : Sun, 12 May 2019 23:24:43 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sun, 12 May 2019 23:24:43 -0400
M doc/src/sgml/release-12.sgml
Fix incorrect return value in JSON equality function for scalars
commit : 1171dbde2daef8f0dcd1dc1e54531a0d8dd34d88
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 13 May 2019 09:11:50 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 13 May 2019 09:11:50 +0900
equalsJsonbScalarValue() uses a boolean as return type, however for one
code path -1 gets returned, which is confusing. The origin of the
confusion is visibly that this code got copy-pasted from
compareJsonbScalarValue() since it has been introduced in d1d50bf.
No backpatch, as this is only cosmetic.
Author: Rikard Falkeborn
Discussion: https://postgr.es/m/CADRDgG7mJnek6HNW13f+LF6V=6gag9PM+P7H5dnyWZAv49aBGg@mail.gmail.com
M src/backend/utils/adt/jsonb_util.c
Fix misoptimization of "{1,1}" quantifiers in regular expressions.
commit : 8a29ed05302ea18b4be177c2d1181b43706af45f
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 12 May 2019 18:53:12 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 12 May 2019 18:53:12 -0400
A bounded quantifier with m = n = 1 might be thought a no-op. But
according to our documentation (which traces back to Henry Spencer's
original man page) it still imposes greediness, or non-greediness in the
case of the non-greedy variant "{1,1}?", on whatever it's attached to.
This turns out not to work though, because parseqatom() optimizes away
the m = n = 1 case without regard for whether it's supposed to change
the greediness of the argument RE.
We can fix this by just not applying the optimization when the greediness
needs to change; the subsequent general cases handle it fine.
The three cases in which we can still apply the optimization are
(a) no quantifier, or quantifier does not impose a preference;
(b) atom has no greediness property, implying it cannot match a
variable amount of text anyway; or
(c) quantifier's greediness is same as atom's.
Note that in most cases where one of these applies, we'd have exited
earlier in the "not a messy case" fast path. I think it's now only
possible to get to the optimization when the atom involves capturing
parentheses or a non-top-level backref.
Back-patch to all supported branches. I'd ordinarily be hesitant to
put a subtle behavioral change into back branches, but in this case
it's very hard to see a reason why somebody would write "{1,1}?" unless
they're trying to get the documented change-of-greediness behavior.
Discussion: https://postgr.es/m/5bb27a41-350d-37bf-901e-9d26f5592dd0@charter.net
M src/backend/regex/regcomp.c
M src/test/regress/expected/regex.out
M src/test/regress/sql/regex.sql
Fail pgwin32_message_to_UTF16() for SQL_ASCII messages.
commit : d02768ddd1791bab742cf131de726d0a36b3f337
author : Noah Misch <noah@leadboat.com>
date : Sun, 12 May 2019 10:33:05 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sun, 12 May 2019 10:33:05 -0700
The function had been interpreting SQL_ASCII messages as UTF8, throwing
an error when they were invalid UTF8. The new behavior is consistent
with pg_do_encoding_conversion(). This affects LOG_DESTINATION_STDERR
and LOG_DESTINATION_EVENTLOG, which will send untranslated bytes to
write() and ReportEventA(). On buildfarm member bowerbird, enabling
log_connections caused an error whenever the role name was not valid
UTF8. Back-patch to 9.4 (all supported versions).
Discussion: https://postgr.es/m/20190512015615.GD1124997@rfd.leadboat.com
M src/backend/utils/mb/mbutils.c
M src/bin/pg_dump/t/010_dump_connstr.pl
M src/bin/scripts/t/200_connstr.pl
Rearrange pgstat_bestart() to avoid failures within its critical section.
commit : 85ccb6899c6c8639bb3e5962ea3bcce5d886e613
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 11 May 2019 21:27:13 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sat, 11 May 2019 21:27:13 -0400
We long ago decided to design the shared PgBackendStatus data structure to
minimize the cost of writing status updates, which means that writers just
have to increment the st_changecount field twice. That isn't hooked into
any sort of resource management mechanism, which means that if something
were to throw error between the two increments, the st_changecount field
would be left odd indefinitely. That would cause readers to lock up.
Now, since it's also a bad idea to leave the field odd for longer than
absolutely necessary (because readers will spin while we have it set),
the expectation was that we'd treat these segments like spinlock critical
sections, with only short, more or less straight-line, code in them.
That was fine as originally designed, but commit 9029f4b37 broke it
by inserting a significant amount of non-straight-line code into
pgstat_bestart(), code that is very capable of throwing errors, not to
mention taking a significant amount of time during which readers will spin.
We have a report from Neeraj Kumar of readers actually locking up, which
I suspect was due to an encoding conversion error in X509_NAME_to_cstring,
though conceivably it was just a garden-variety OOM failure.
Subsequent commits have loaded even more dubious code into pgstat_bestart's
critical section (and commit fc70a4b0d deserves some kind of booby prize
for managing to miss the critical section entirely, although the negative
consequences seem minimal given that the PgBackendStatus entry should be
seen by readers as inactive at that point).
The right way to fix this mess seems to be to compute all these values
into a local copy of the process' PgBackendStatus struct, and then just
copy the data back within the critical section proper. This plan can't
be implemented completely cleanly because of the struct's heavy reliance
on out-of-line strings, which we must initialize separately within the
critical section. But still, the critical section is far smaller and
safer than it was before.
In hopes of forestalling future errors of the same ilk, rename the
macros for st_changecount management to make it more apparent that
the writer-side macros create a critical section. And to prevent
the worst consequences if we nonetheless manage to mess it up anyway,
adjust those macros so that they really are a critical section, ie
they now bump CritSectionCount. That doesn't add much overhead, and
it guarantees that if we do somehow throw an error while the counter
is odd, it will lead to PANIC and a database restart to reset shared
memory.
Back-patch to 9.5 where the problem was introduced.
In HEAD, also fix an oversight in commit b0b39f72b: it failed to teach
pgstat_read_current_status to copy st_gssstatus data from shared memory to
local memory. Hence, subsequent use of that data within the transaction
would potentially see changing data that it shouldn't see.
Discussion: https://postgr.es/m/CAPR3Wj5Z17=+eeyrn_ZDG3NQGYgMEOY6JV6Y-WRRhGgwc16U3Q@mail.gmail.com
M src/backend/postmaster/pgstat.c
M src/include/pgstat.h
docs: remove second mention of btree max length reduction
commit : 4217d15d91128355ea13e6fb9c031b826e2a1335
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 11 May 2019 18:24:31 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 11 May 2019 18:24:31 -0400
I already added that to the incompatibility section as a separate item.
Reported-by: Peter Geoghegan
M doc/src/sgml/release-12.sgml
doc: remove pg_config mention from PG 12 release notes
commit : 31f11f964734dbe2af2915182bf79f69e337d4d7
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 11 May 2019 17:59:58 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 11 May 2019 17:59:58 -0400
Reported-by: Tom Lane
Discussion: https://postgr.es/m/28209.1556556696@sss.pgh.pa.us
M doc/src/sgml/release-12.sgml
docs: PG 12 release notes, mention that REINDEX could now fail
commit : d56fd6357a5e0e76fecf20c3dc762c5301290331
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 11 May 2019 16:42:05 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 11 May 2019 16:42:05 -0400
This is because of the new tid in the index entry.
Reported-by: Peter Geoghegan
M doc/src/sgml/release-12.sgml
docs: add links from the PG 12 release notes to the main docs
commit : 1708974485e82e1cf4694c683faa70fc5bcf142c
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 11 May 2019 16:17:18 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 11 May 2019 16:17:18 -0400
M doc/src/sgml/release-12.sgml
docs: adjust PG 12 floating point item
commit : 0edc8fc47bc4482ceac85b09575d6372dbbc0bbf
author : Bruce Momjian <bruce@momjian.us>
date : Sat, 11 May 2019 10:29:30 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Sat, 11 May 2019 10:29:30 -0400
Reported-by: Andrew Gierth
Discussion: https://postgr.es/m/87r295hjur.fsf@news-spur.riddles.org.uk
M doc/src/sgml/release-12.sgml
Honor TEMP_CONFIG in TAP suites.
commit : 54c2ecb56707ed00844b8678a79570dd34cb95a3
author : Noah Misch <noah@leadboat.com>
date : Sat, 11 May 2019 00:22:38 -0700
committer: Noah Misch <noah@leadboat.com>
date : Sat, 11 May 2019 00:22:38 -0700
The buildfarm client uses TEMP_CONFIG to implement its extra_config
setting. Except for stats_temp_directory, extra_config now applies to
TAP suites; extra_config values seen in the past month are compatible
with this. Back-patch to 9.6, where PostgresNode was introduced, so the
buildfarm can rely on it sooner.
Reviewed by Andrew Dunstan and Tom Lane.
Discussion: https://postgr.es/m/20181229021950.GA3302966@rfd.leadboat.com
M src/bin/pg_ctl/t/001_start_stop.pl
M src/test/perl/PostgresNode.pm
Fix error reporting in reindexdb
commit : e51bad8fb4c3f0ad5cb173034afdc0b349c7e488
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 11 May 2019 13:00:54 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 11 May 2019 13:00:54 +0900
When failing to reindex a table or an index, reindexdb would generate an
extra error message related to a database failure, which is misleading.
Backpatch all the way down, as this has been introduced by 85e9a5a0.
Discussion: https://postgr.es/m/CAOBaU_Yo61RwNO3cW6WVYWwH7EYMPuexhKqufb2nFGOdunbcHw@mail.gmail.com
Author: Julien Rouhaud
Reviewed-by: Daniel Gustafsson, Álvaro Herrera, Tom Lane, Michael
Paquier
Backpatch-through: 9.4
M src/bin/scripts/reindexdb.c
Fix editing error in floating-point docs.
commit : b721e201a0bcf0f9e1795c295e134e47d698e80c
author : Andrew Gierth <rhodiumtoad@postgresql.org>
date : Sat, 11 May 2019 03:23:55 +0100
committer: Andrew Gierth <rhodiumtoad@postgresql.org>
date : Sat, 11 May 2019 03:23:55 +0100
My fault; the error was introduced in the Ryu patch.
M doc/src/sgml/datatype.sgml
doc: add Heikki to PG 12 release note btree item
commit : 064df0edfee91d3843d54d1f67c05a4634690a12
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 22:11:13 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 22:11:13 -0400
Reported-by: Peter Geoghegan
Discussion: https://postgr.es/m/CAH2-WzkrX-aA7d3OYtQT+8Mspq+tU5vwuVz=FTzMH3CdrSyprA@mail.gmail.com
M doc/src/sgml/release-12.sgml
doc: improve PG 12 item on partitioned tables
commit : 13d258ec0e55ebc4378e848934f0f4c0ffac0a6f
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 21:22:53 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 21:22:53 -0400
Reported-by: Amit Langote
Discussion: https://postgr.es/m/5936b052-5d92-a2c9-75d2-0245fb2330b5@lab.ntt.co.jp
M doc/src/sgml/release-12.sgml
doc: reorder attribution of PG 12 btree item
commit : 05f9eba3498f4dbc8687f66eff53a2bfb88f2595
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 21:16:33 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 21:16:33 -0400
Reported-by: Alexander Korotkov
Discussion: https://postgr.es/m/CAPpHfdvkM-PkyrK6LQitJUDmC_1kOCEtTuseoVhCT=ew0XJmGg@mail.gmail.com
M doc/src/sgml/release-12.sgml
docs: properly attribute PG 12 rel item to James Coleman
commit : 8aa1b0885e3d248dbf3e0b0c544125d13dbc36d0
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 21:06:38 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 21:06:38 -0400
Reported-by: David Rowley
Discussion: https://postgr.es/m/CAKJS1f-NDmeA_tb0oRFhrgf19xq3A9MeoyMcckY04Ct=_i0c2A@mail.gmail.com
M doc/src/sgml/release-12.sgml
docs: PG 12 docs, clarify btree index changes
commit : 809e248299894b02e8f4eb3ee17829b2ae14ce9d
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 21:03:31 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 21:03:31 -0400
Reported-by: Peter Geoghegan
Discussion: https://postgr.es/m/CAH2-WzkSYOM1GJVGtAbRW-OqymoCD=QWYG6ro+GaoOW-jPRuDQ@mail.gmail.com
M doc/src/sgml/release-12.sgml
doc: PG 12 release note adjustment
commit : b299efaea433a7d2c04ce124e4f6588807bbe87a
author : Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 20:25:52 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Fri, 10 May 2019 20:25:52 -0400
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20190510013449.GL3925@telsasoft.com
M doc/src/sgml/release-12.sgml
Remove reindex_catalog test from test schedules.
commit : 5997a8f4d7478ae6bac4dab12ca1f883e41a7aa1
author : Andres Freund <andres@anarazel.de>
date : Sun, 5 May 2019 23:31:58 -0700
committer: Andres Freund <andres@anarazel.de>
date : Sun, 5 May 2019 23:31:58 -0700
As none of the approaches for avoiding the deadlock issues seem
promising enough, and all the expected reindex related changes have
been made, apply 60c2951e1bab7e to master as well.
Discussion: https://postgr.es/m/4622.1556982247@sss.pgh.pa.us
M src/test/regress/expected/reindex_catalog.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
M src/test/regress/sql/reindex_catalog.sql
Cope with EINVAL and EIDRM shmat() failures in PGSharedMemoryAttach.
commit : 610747d86e46ae6e94b7288393d08823cc39b498
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 May 2019 14:56:41 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 10 May 2019 14:56:41 -0400
There's a very old race condition in our code to see whether a pre-existing
shared memory segment is still in use by a conflicting postmaster: it's
possible for the other postmaster to remove the segment in between our
shmctl() and shmat() calls. It's a narrow window, and there's no risk
unless both postmasters are using the same port number, but that's possible
during parallelized "make check" tests. (Note that while the TAP tests
take some pains to choose a randomized port number, pg_regress doesn't.)
If it does happen, we treated that as an unexpected case and errored out.
To fix, allow EINVAL to be treated as segment-not-present, and the same
for EIDRM on Linux. AFAICS, the considerations here are basically
identical to the checks for acceptable shmctl() failures, so I documented
and coded it that way.
While at it, adjust PGSharedMemoryAttach's API to remove its undocumented
dependency on UsedShmemSegAddr in favor of passing the attach address
explicitly. This makes it easier to be sure we're using a null shmaddr
when probing for segment conflicts (thus avoiding questions about what
EINVAL means). I don't think there was a bug there, but it required
fragile assumptions about the state of UsedShmemSegAddr during
PGSharedMemoryIsInUse.
Commit c09850992 may have made this failure more probable by applying
the conflicting-segment tests more often. Hence, back-patch to all
supported branches, as that was.
Discussion: https://postgr.es/m/22224.1557340366@sss.pgh.pa.us
M src/backend/port/sysv_shmem.c
doc: add markup for PG 12 release note text
commit : c65bcfe9aeecae1c6204ad60612fae43669a88b0
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 23:26:48 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 23:26:48 -0400
I will add links to other parts of the docs later.
M doc/src/sgml/release-12.sgml
doc: PG 12 wording improvments
commit : d0bbf871ca243eafcac7a84138741521c1aea3d2
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 20:58:02 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 20:58:02 -0400
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20190510001335.GJ3925@telsasoft.com
M doc/src/sgml/release-12.sgml
Fix and improve description of locktag types in lock.h
commit : 752f06443fba7e906cd98987f247297663f19a16
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 10 May 2019 09:35:27 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 10 May 2019 09:35:27 +0900
The description of the lock type for speculative insertions was
incorrect, being copy-pasted from another one.
As discussed, also move the description for all the fields of lock tag
types from the structure listing lock tag types to the set of macros
setting each LOCKTAG.
Author: John Naylor
Discussion: https://postgr.es/m/CACPNZCtA0-ybaC4fFfaDq_8p_TUOLvGxZH9Dm-=TMHZJarBa7Q@mail.gmail.com
M src/include/storage/lock.h
doc: more PG 12 wording adjustments
commit : 97b1654da7dd38fa50c9b6139f4213a1c47f0c39
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 20:32:35 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 20:32:35 -0400
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20190510001959.GK3925@telsasoft.com
M doc/src/sgml/release-12.sgml
doc: fix capitalization in PG 12 release notes
commit : 32fe7ee2dd2b2aa8620e69451f60b2b35989677c
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 20:10:17 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 20:10:17 -0400
Reported-by: Thomas Munro
Discussion: https://postgr.es/m/CA+hUKGJpep8uSXoDtVF6iROCRKce-39HEhDPUaYFyMn0U5e9ug@mail.gmail.com
M doc/src/sgml/release-12.sgml
doc: more PG 12 release note adjustments
commit : 79697d039f567cd52d844077244fb85df10dce19
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 19:59:59 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 19:59:59 -0400
This adds two more items that should have been included in the
beginning.
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20190508203204.GA25482@telsasoft.com
M doc/src/sgml/release-12.sgml
docs: update release notes with fixes
commit : 81ddfa2e4d9350eb68f28cde8ae6a7e0b39ef2ac
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 19:27:03 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 19:27:03 -0400
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/20190508203204.GA25482@telsasoft.com
M doc/src/sgml/release-12.sgml
Improve and fix some error handling for REINDEX INDEX/TABLE CONCURRENTLY
commit : 508300e2e141a9fd87758ce01374c5b0597986fd
author : Michael Paquier <michael@paquier.xyz>
date : Fri, 10 May 2019 08:18:46 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Fri, 10 May 2019 08:18:46 +0900
This improves the user experience when it comes to restrict several
flavors of REINDEX CONCURRENTLY. First, for INDEX, remove a restriction
on shared relations as we already check after catalog relations. Then,
for TABLE, add a proper error message when attempting to run the command
on system catalogs. The code path of CREATE INDEX CONCURRENTLY already
complains about that, but if a REINDEX is issued then then the error
generated is confusing.
While on it, add more tests to check restrictions on catalog indexes and
on toast table/index for catalogs. Some error messages are improved,
with wording suggestion coming from Tom Lane.
Reported-by: Tom Lane
Author: Michael Paquier
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/23694.1556806002@sss.pgh.pa.us
M src/backend/commands/indexcmds.c
M src/test/regress/expected/create_index.out
M src/test/regress/sql/create_index.sql
Repair issues with faulty generation of merge-append plans.
commit : 24c19e9f66863d83009a370604e40b1eaa71bcdd
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 9 May 2019 16:52:48 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 9 May 2019 16:52:48 -0400
create_merge_append_plan failed to honor the CP_EXACT_TLIST flag:
it would generate the expected targetlist but then it felt free to
add resjunk sort targets to it. This demonstrably leads to assertion
failures in v11 and HEAD, and it's probably just accidental that we
don't see the same in older branches. I've not looked into whether
there would be any real-world consequences in non-assert builds.
In HEAD, create_append_plan has sprouted the same problem, so fix
that too (although we do not have any test cases that seem able to
reach that bug). This is an oversight in commit 3fc6e2d7f which
invented the CP_EXACT_TLIST flag, so back-patch to 9.6 where that
came in.
convert_subquery_pathkeys would create pathkeys for subquery output
values if they match any EquivalenceClass known in the outer query
and are available in the subquery's syntactic targetlist. However,
the second part of that condition is wrong, because such values might
not appear in the subquery relation's reltarget list, which would
mean that they couldn't be accessed above the level of the subquery
scan. We must check that they appear in the reltarget list, instead.
This can lead to dropping knowledge about the subquery's sort
ordering, but I believe it's okay, because any sort key that the
outer query actually has any interest in would appear in the
reltarget list.
This second issue is of very long standing, but right now there's no
evidence that it causes observable problems before 9.6, so I refrained
from back-patching further than that. We can revisit that choice if
somebody finds a way to make it cause problems in older branches.
(Developing useful test cases for these issues is really problematic;
fixing convert_subquery_pathkeys removes the only known way to exhibit
the create_merge_append_plan bug, and neither of the test cases added
by this patch causes a problem in all branches, even when considering
the issues separately.)
The second issue explains bug #15795 from Suresh Kumar R ("could not
find pathkey item to sort" with nested DISTINCT queries). I stumbled
across the first issue while investigating that.
Discussion: https://postgr.es/m/15795-fadb56c8e44ee73c@postgresql.org
M src/backend/optimizer/path/pathkeys.c
M src/backend/optimizer/plan/createplan.c
M src/test/regress/expected/union.out
M src/test/regress/sql/union.sql
doc: update PG 12 release notes, v2
commit : 64084d6857b1d8ac05ae46f658b6c244aa6ab591
author : Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 16:44:27 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Thu, 9 May 2019 16:44:27 -0400
Adjustments requested by reviewers.
Reported-by: Amit Kapila, Thomas Munro, Andrew Gierth, Amit Langote, Oleg Bartunov, Michael Paquier, Alvaro Herrera, Tatsuo Ishii
Discussion: https://postgr.es/m/20190506233029.ozwged67i7s4qd6c@momjian.us
M doc/src/sgml/release-12.sgml
Doc: Update FDW documentation about GetForeignUpperPaths().
commit : a0be05bab062eff16eafce3df73b3df453a694f4
author : Etsuro Fujita <efujita@postgresql.org>
date : Thu, 9 May 2019 19:50:15 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Thu, 9 May 2019 19:50:15 +0900
In commit d50d172e51, which added support for LIMIT/OFFSET pushdown in
postgres_fdw, a new struct was introduced as the extra parameter of
GetForeignUpperPaths() set for UPPERREL_FINAL, but I forgot to update
the documentation to mention that.
Author: Etsuro Fujita
Discussion: https://postgr.es/m/CAPmGK17uSXQDe31oRb-z1nYyT6vVzkstZkA3_Wbq38U92b9BmQ%40mail.gmail.com
M doc/src/sgml/fdwhandler.sgml
postgres_fdw: Fix cost estimation for aggregate pushdown.
commit : edbcbe277d795ecc339b0e4fa29bae42ce1a7be9
author : Etsuro Fujita <efujita@postgresql.org>
date : Thu, 9 May 2019 18:39:23 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Thu, 9 May 2019 18:39:23 +0900
In commit 7012b132d0, which added support for aggregate pushdown in
postgres_fdw, the expense of evaluating the final scan/join target
computed by make_group_input_target() was not accounted for at all in
costing aggregate pushdown paths with local statistics. The right fix
for this would be to have a separate upper stage to adjust the final
scan/join relation (see comments for apply_scanjoin_target_to_paths());
but for now, fix by adding the tlist eval cost when costing aggregate
pushdown paths with local statistics.
Apply this to HEAD only to avoid destabilizing existing plan choices.
Author: Etsuro Fujita
Reviewed-By: Antonin Houska
Discussion: https://postgr.es/m/5C66A056.60007%40lab.ntt.co.jp
M contrib/postgres_fdw/postgres_fdw.c
M src/backend/optimizer/plan/planner.c
Fix SxactGlobalXmin tracking.
commit : 47a338cfcd67139a1f91892b080934fcfc3aea03
author : Thomas Munro <tmunro@postgresql.org>
date : Thu, 9 May 2019 19:11:46 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Thu, 9 May 2019 19:11:46 +1200
Commit bb16aba50 broke the code that maintains SxactGlobalXmin. It
could get stuck when a well-timed READ ONLY transaction runs. If
SxactGlobalXmin stops advancing, transactions on the
FinishedSerializableTransactions queue are never cleaned up, so
resources are effectively leaked. Revert that hunk of the commit.
Also revert another similar hunk that was probably harmless, but
unnecessary and unjustified, relating to the DOOMED flag in case of
RO_SAFE early release.
Author: Thomas Munro
Reported-by: Tom Lane
Discussion: https://postgr.es/m/16170.1557251214%40sss.pgh.pa.us
M src/backend/storage/lmgr/predicate.c
pg_controldata: Add common gettext flags
commit : cd805f46d857291b26ba6eb491ce11b6e0fc9ad3
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 9 May 2019 09:15:59 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 9 May 2019 09:15:59 +0200
So it picks up strings in pg_log_* calls. This was forgotten when it
was added to all other relevant subdirectories.
M src/bin/pg_controldata/nls.mk
Fix grammar in error message
commit : 02daece4ab4cd85b80d04469056e5b631918c9d6
author : Peter Eisentraut <peter@eisentraut.org>
date : Thu, 9 May 2019 09:14:37 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Thu, 9 May 2019 09:14:37 +0200
M doc/src/sgml/plpgsql.sgml
M src/pl/plpgsql/src/pl_exec.c
M src/test/regress/expected/plpgsql.out
Clean up the behavior and API of catalog.c's is-catalog-relation tests.
commit : 2d7d946cd323ce1c1d3f3ef0e5f2f41591afc1b9
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 8 May 2019 23:27:29 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Wed, 8 May 2019 23:27:29 -0400
The right way for IsCatalogRelation/Class to behave is to return true
for OIDs less than FirstBootstrapObjectId (not FirstNormalObjectId),
without any of the ad-hoc fooling around with schema membership.
The previous code was wrong because (1) it claimed that
information_schema tables were not catalog relations but their toast
tables were, which is silly; and (2) if you dropped and recreated
information_schema, which is a supported operation, the behavior
changed. That's even sillier. With this definition, "catalog
relations" are exactly the ones traceable to the postgres.bki data,
which seems like what we want.
With this simplification, we don't actually need access to the pg_class
tuple to identify a catalog relation; we only need its OID. Hence,
replace IsCatalogClass with "IsCatalogRelationOid(oid)". But keep
IsCatalogRelation as a convenience function.
This allows fixing some arguably-wrong semantics in contrib/sepgsql and
ReindexRelationConcurrently, which were using an IsSystemNamespace test
where what they really should be using is IsCatalogRelationOid. The
previous coding failed to protect toast tables of system catalogs, and
also was not on board with the general principle that user-created tables
do not become catalogs just by virtue of being renamed into pg_catalog.
We can also get rid of a messy hack in ReindexMultipleTables.
While we're at it, also rename IsSystemNamespace to IsCatalogNamespace,
because the previous name invited confusion with the more expansive
semantics used by IsSystemRelation/Class.
Also improve the comments in catalog.c.
There are a few remaining places in replication-related code that are
special-casing OIDs below FirstNormalObjectId. I'm inclined to think
those are wrong too, and if there should be any special case it should
just extend to FirstBootstrapObjectId. But first we need to debate
whether a FOR ALL TABLES publication should include information_schema.
Discussion: https://postgr.es/m/21697.1557092753@sss.pgh.pa.us
Discussion: https://postgr.es/m/15150.1557257111@sss.pgh.pa.us
M contrib/sepgsql/dml.c
M src/backend/access/transam/varsup.c
M src/backend/catalog/catalog.c
M src/backend/catalog/heap.c
M src/backend/catalog/pg_publication.c
M src/backend/commands/indexcmds.c
M src/backend/commands/tablecmds.c
M src/backend/utils/cache/relcache.c
M src/include/catalog/catalog.h
Fix error status of vacuumdb when multiple jobs are used
commit : 3ae3c18b362817f9412c380539f1a16c7abb79c9
author : Michael Paquier <michael@paquier.xyz>
date : Thu, 9 May 2019 10:29:10 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Thu, 9 May 2019 10:29:10 +0900
When running a batch of VACUUM or ANALYZE commands on a given database,
there were cases where it is possible to have vacuumdb not report an
error where it actually should, leading to incorrect status results.
Author: Julien Rouhaud
Reviewed-by: Amit Kapila, Michael Paquier
Discussion: https://postgr.es/m/CAOBaU_ZuTwz7CtqLYJ1Ouuh272bTQPLN8b1bAPk0bCBm4PDMTQ@mail.gmail.com
Backpatch-through: 9.5
M src/bin/scripts/vacuumdb.c
Remove obsolete nbtree split REDO routine comment.
commit : d95e36dc384e3068ae2db909c228b1800737b18d
author : Peter Geoghegan <pg@bowt.ie>
date : Wed, 8 May 2019 12:47:20 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Wed, 8 May 2019 12:47:20 -0700
Commit dd299df8189, which added suffix truncation to nbtree, simplified
the WAL record format used by page splits. It became necessary to
explicitly WAL-log the new high key for the left half of a split in all
cases, which relieved the REDO routine from having to reconstruct a new
high key for the left page by copying the first item from the right
page. Remove a comment that referred to the previous practice.
M src/backend/access/nbtree/nbtxlog.c
Fix error messages
commit : 61639816b870347677e6e6945604e0d9da1837ca
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 8 May 2019 13:16:54 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Wed, 8 May 2019 13:16:54 -0400
Some messages related to foreign servers were reporting the server name
without quotes, or not at all; our style is to have all names be quoted,
and the server name already appears quoted in a few other messages, so
just add quotes and make them all consistent.
Remove an extra "s" in other messages (typos introduced by myself in
f56f8f8da6af).
M src/backend/commands/foreigncmds.c
M src/backend/commands/tablecmds.c
M src/test/regress/expected/foreign_data.out
Fix documentation for the privileges required for replication functions.
commit : df631ebc737e9d9cdf8d0691969d404f1bd584a4
author : Fujii Masao <fujii@postgresql.org>
date : Thu, 9 May 2019 01:35:13 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Thu, 9 May 2019 01:35:13 +0900
Previously it's documented that use of replication functions is
restricted to superusers. This is true for the functions which
use replication origin, but not for pg_logicl_emit_message() and
functions which use replication slot. For example, not only
superusers but also users with REPLICATION privilege is allowed
to use the functions for replication slot. This commit fixes
the documentation for the privileges required for those replication
functions.
Back-patch to 9.4 (all supported versions).
Author: Matsumura Ryo
Discussion: https://postgr.es/m/03040DFF97E6E54E88D3BFEE5F5480F74ABA6E16@G01JPEXMBYT04
M doc/src/sgml/func.sgml
Fix table lock levels for REINDEX INDEX CONCURRENTLY
commit : add85ead4ab969c1e31d64f4476c2335856f4aa9
author : Peter Eisentraut <peter@eisentraut.org>
date : Wed, 8 May 2019 14:15:01 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Wed, 8 May 2019 14:15:01 +0200
REINDEX CONCURRENTLY locks tables with ShareUpdateExclusiveLock rather
than the ShareLock used by a plain REINDEX. However,
RangeVarCallbackForReindexIndex() was not updated for that and still
used the ShareLock only. This would lead to lock upgrades later,
leading to possible deadlocks.
Reported-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://www.postgresql.org/message-id/flat/20190430151735.wi52sxjvxsjvaxxt%40alap3.anarazel.de
M src/backend/commands/indexcmds.c
Probe only 127.0.0.1 when looking for ports on Unix.
commit : 8efe710d9c84502b3e6a9487937bccf881f56d9c
author : Thomas Munro <tmunro@postgresql.org>
date : Mon, 6 May 2019 15:02:41 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Mon, 6 May 2019 15:02:41 +1200
Commit c0985099, later adjusted by commit 4ab02e81, probed 0.0.0.0
in addition to 127.0.0.1, for the benefit of Windows build farm
animals. It isn't really useful on Unix systems, and turned out to
be a bit inconvenient to users of some corporate firewall software.
Switch back to probing just 127.0.0.1 on non-Windows systems.
Back-patch to 9.6, like the earlier changes.
Discussion: https://postgr.es/m/CA%2BhUKG%2B21EPwfgs4m%2BtqyRtbVqkOUvP8QQ8sWk9%2Bh55Aub1H3A%40mail.gmail.com
M src/test/perl/PostgresNode.pm
Fix copy-and-paste mistakes in documentation.
commit : 098344be663f5fc0ad166e7a9e1cd37721ee34d9
author : Thomas Munro <tmunro@postgresql.org>
date : Wed, 8 May 2019 21:14:14 +1200
committer: Thomas Munro <tmunro@postgresql.org>
date : Wed, 8 May 2019 21:14:14 +1200
Reported-by: Vik Fearing
M doc/src/sgml/ref/create_table.sgml
M doc/src/sgml/ref/create_table_as.sgml
Add missing periods to comments.
commit : b7434dc007252d7a5e5f7f85700bd7400b1db201
author : Etsuro Fujita <efujita@postgresql.org>
date : Wed, 8 May 2019 16:49:09 +0900
committer: Etsuro Fujita <efujita@postgresql.org>
date : Wed, 8 May 2019 16:49:09 +0900
M src/include/nodes/pathnodes.h
Remove leftover reference to old "flat file" mechanism in a comment.
commit : 256be1050cbbf90b1e44d11c8ed10f98255aa27d
author : Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 8 May 2019 09:32:34 +0300
committer: Heikki Linnakangas <heikki.linnakangas@iki.fi>
date : Wed, 8 May 2019 09:32:34 +0300
The flat file mechanism was removed in PostgreSQL 9.0.
M src/backend/access/transam/xact.c
Correct obsolete nbtsort.c minimum key comment.
commit : d65b5ccad626e1942c862e8a70f56ad7ee7a8003
author : Peter Geoghegan <pg@bowt.ie>
date : Tue, 7 May 2019 21:42:12 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Tue, 7 May 2019 21:42:12 -0700
It is no longer possible under any circumstances for nbtree code to
reconstruct a strict lower bound key (parent page's pivot tuple key) for
a right sibling page by retrieving the first item in the right sibling
page.
M src/backend/access/nbtree/nbtsort.c
Add jsonpath_encoding_1.out changes missed in 29ceacc3f9
commit : e5f978631722bb3cac42f0eb6e65e947e0f088ec
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Wed, 8 May 2019 01:55:31 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Wed, 8 May 2019 01:55:31 +0300
Reported-by: Tom Lane
Discussion: https://postgr.es/m/14305.1557268259%40sss.pgh.pa.us
M src/test/regress/expected/jsonpath_encoding_1.out
Remove word "singleton" out of jsonpath docs
commit : 53ae0b16d6f60a15427e081091b2b81e36e674ee
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Tue, 30 Apr 2019 01:12:05 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Tue, 30 Apr 2019 01:12:05 +0300
Word "singleton" is hard for user understanding, especially taking into account
there is only one place it's used in the docs and there is even no definition.
Use more evident wording instead.
Discussion: https://postgr.es/m/23737.1556550645%40sss.pgh.pa.us
M doc/src/sgml/func.sgml
Improve error reporting in jsonpath
commit : 29ceacc3f93720d3ebb7e7e999f8b7fe9622389c
author : Alexander Korotkov <akorotkov@postgresql.org>
date : Tue, 23 Apr 2019 17:43:09 +0300
committer: Alexander Korotkov <akorotkov@postgresql.org>
date : Tue, 23 Apr 2019 17:43:09 +0300
This commit contains multiple improvements to error reporting in jsonpath
including but not limited to getting rid of following things:
* definition of error messages in macros,
* errdetail() when valueable information could fit to errmsg(),
* word "singleton" which is not properly explained anywhere,
* line breaks in error messages.
Reported-by: Tom Lane
Discussion: https://postgr.es/m/14890.1555523005%40sss.pgh.pa.us
Author: Alexander Korotkov
Reviewed-by: Tom Lane
M src/backend/utils/adt/jsonpath_exec.c
M src/backend/utils/adt/jsonpath_gram.y
M src/backend/utils/adt/jsonpath_scan.l
M src/test/regress/expected/jsonb_jsonpath.out
M src/test/regress/expected/jsonpath.out
M src/test/regress/expected/jsonpath_encoding.out
M src/test/regress/expected/jsonpath_encoding_1.out
Add TRUNCATE parameter to VACUUM.
commit : b84dbc8eb80b43e554891c459a19969d9fbdefe5
author : Fujii Masao <fujii@postgresql.org>
date : Wed, 8 May 2019 02:10:33 +0900
committer: Fujii Masao <fujii@postgresql.org>
date : Wed, 8 May 2019 02:10:33 +0900
This commit adds new parameter to VACUUM command, TRUNCATE,
which specifies that VACUUM should attempt to truncate off
any empty pages at the end of the table and allow the disk space
for the truncated pages to be returned to the operating system.
This parameter, if specified, overrides the vacuum_truncate
reloption. If neither the reloption nor the VACUUM option is
used, the default is true, as before.
Author: Fujii Masao
Reviewed-by: Julien Rouhaud, Masahiko Sawada
Discussion: https://postgr.es/m/CAD21AoD+qtrSDL=GSma4Wd3kLYLeRC0hPna-YAdkDeV4z156vg@mail.gmail.com
M doc/src/sgml/ref/create_table.sgml
M doc/src/sgml/ref/vacuum.sgml
M src/backend/access/heap/vacuumlazy.c
M src/backend/commands/vacuum.c
M src/backend/postmaster/autovacuum.c
M src/bin/psql/tab-complete.c
M src/include/commands/vacuum.h
M src/test/regress/expected/vacuum.out
M src/test/regress/sql/vacuum.sql
Fix typos and clarify a comment
commit : 98719af6c2e30d538cd05cfe044f58ba4067b52b
author : Magnus Hagander <magnus@hagander.net>
date : Tue, 7 May 2019 18:26:09 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Tue, 7 May 2019 18:26:09 +0200
Author: Daniel Gustafsson <daniel@yesql.se>
M src/backend/utils/adt/jsonpath_exec.c
Avoid "invalid memory alloc request size" while reading pg_stat_activity.
commit : 8d0ddccec6366a2851da7d350b33659203aa644b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 7 May 2019 11:41:37 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 7 May 2019 11:41:37 -0400
On a 64-bit machine, if you set track_activity_query_size and
max_connections such that their product exceeds 1GB, shared memory
setup will still succeed (given enough RAM), but attempts to read
pg_stat_activity fail with "invalid memory alloc request size".
Work around that by using MemoryContextAllocHuge to allocate the
local copy of the activity strings. Using the "huge" API costs us
nothing extra in normal cases, and it seems better than throwing
an error and/or explaining to people why they can't do this.
This situation seems insanely profligate today, but who knows what
people will consider normal in ten or twenty years? So let's fix it
in HEAD but not worry about a back-patch.
Per report from James Tomson.
Discussion: https://postgr.es/m/1CFDCCD6-B268-48D8-85C8-400D2790B2C3@pushd.com
M src/backend/postmaster/pgstat.c
doc: Generate keywords table automatically
commit : b753bc0c84e51c200ec7de6cefb6f689d13fef62
author : Peter Eisentraut <peter@eisentraut.org>
date : Tue, 7 May 2019 15:29:39 +0200
committer: Peter Eisentraut <peter@eisentraut.org>
date : Tue, 7 May 2019 15:29:39 +0200
The SQL keywords table in the documentation had until now been
generated by some ad hoc scripting outside the source tree once for
each major release. This changes it to an automated process.
We have the PostgreSQL keywords available in a parseable format in
parser/kwlist.h. For the relevant SQL standard versions, keep the
keyword lists in new text files. A new script
generate-keywords-table.pl pulls it all together and produces a
DocBook table.
The final output in the documentation should be identical after this
change.
Discussion: https://www.postgresql.org/message-id/flat/07daeadd-8c82-0d95-5e19-e350502cb749%402ndquadrant.com
M doc/src/sgml/.gitignore
M doc/src/sgml/Makefile
M doc/src/sgml/filelist.sgml
A doc/src/sgml/generate-keywords-table.pl
M doc/src/sgml/keywords.sgml
A doc/src/sgml/keywords/sql1992-nonreserved.txt
A doc/src/sgml/keywords/sql1992-reserved.txt
A doc/src/sgml/keywords/sql2008-02-nonreserved.txt
A doc/src/sgml/keywords/sql2008-02-reserved.txt
A doc/src/sgml/keywords/sql2008-09-nonreserved.txt
A doc/src/sgml/keywords/sql2008-09-reserved.txt
A doc/src/sgml/keywords/sql2008-14-nonreserved.txt
A doc/src/sgml/keywords/sql2008-14-reserved.txt
A doc/src/sgml/keywords/sql2011-02-nonreserved.txt
A doc/src/sgml/keywords/sql2011-02-reserved.txt
A doc/src/sgml/keywords/sql2011-09-nonreserved.txt
A doc/src/sgml/keywords/sql2011-09-reserved.txt
A doc/src/sgml/keywords/sql2011-14-nonreserved.txt
A doc/src/sgml/keywords/sql2011-14-reserved.txt
Revert "Avoid the creation of the free space map for small heap relations".
commit : 7db0cde6b58eef2ba0c70437324cbc7622230320
author : Amit Kapila <akapila@postgresql.org>
date : Tue, 7 May 2019 09:30:24 +0530
committer: Amit Kapila <akapila@postgresql.org>
date : Tue, 7 May 2019 09:30:24 +0530
This feature was using a process local map to track the first few blocks
in the relation. The map was reset each time we get the block with enough
freespace. It was discussed that it would be better to track this map on
a per-relation basis in relcache and then invalidate the same whenever
vacuum frees up some space in the page or when FSM is created. The new
design would be better both in terms of API design and performance.
List of commits reverted, in reverse chronological order:
06c8a5090e Improve code comments in b0eaa4c51b.
13e8643bfc During pg_upgrade, conditionally skip transfer of FSMs.
6f918159a9 Add more tests for FSM.
9c32e4c350 Clear the local map when not used.
29d108cdec Update the documentation for FSM behavior..
08ecdfe7e5 Make FSM test portable.
b0eaa4c51b Avoid creation of the free space map for small heap relations.
Discussion: https://postgr.es/m/20190416180452.3pm6uegx54iitbt5@alap3.anarazel.de
M contrib/pageinspect/expected/page.out
M contrib/pageinspect/sql/page.sql
M contrib/pgstattuple/pgstatapprox.c
M doc/src/sgml/pgfreespacemap.sgml
M doc/src/sgml/pgstattuple.sgml
M doc/src/sgml/ref/pgupgrade.sgml
M doc/src/sgml/storage.sgml
M src/backend/access/brin/brin.c
M src/backend/access/brin/brin_pageops.c
M src/backend/access/heap/hio.c
M src/backend/access/heap/vacuumlazy.c
M src/backend/access/transam/xact.c
M src/backend/storage/freespace/README
M src/backend/storage/freespace/freespace.c
M src/backend/storage/freespace/indexfsm.c
M src/bin/pg_upgrade/info.c
M src/bin/pg_upgrade/pg_upgrade.h
M src/bin/pg_upgrade/relfilenode.c
M src/include/storage/freespace.h
D src/test/regress/expected/fsm.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
D src/test/regress/sql/fsm.sql
Remove some code related to 7.3 and older servers from tools of src/bin/
commit : af82f95abb23a56d18fd009ef9eca68ef803a041
author : Michael Paquier <michael@paquier.xyz>
date : Tue, 7 May 2019 09:39:39 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Tue, 7 May 2019 09:39:39 +0900
This code was broken as of 582edc3, and is most likely not used anymore.
Note that pg_dump supports servers down to 8.0, and psql has code to
support servers down to 7.4.
Author: Julien Rouhaud
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/CAOBaU_Y5y=zo3+2gf+2NJC1pvMYPcbRXoQaPXx=U7+C8Qh4CzQ@mail.gmail.com
M src/bin/scripts/common.c
docs: fist draft version of the PG 12 release notes
commit : bdf595adbca195fa54a909c74a5233ebc30641a1
author : Bruce Momjian <bruce@momjian.us>
date : Mon, 6 May 2019 19:02:34 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Mon, 6 May 2019 19:02:34 -0400
Still needs text markup, links, word wrap, and indenting.
M doc/src/sgml/release-12.sgml
Revert "Make pg_dump emit ATTACH PARTITION instead of PARTITION OF"
commit : a1ec7402e9a0392f95bc79542af0efcd5c6e7929
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 6 May 2019 12:23:49 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 6 May 2019 12:23:49 -0400
... and fallout (from branches 10, 11 and master). The change was
ill-considered, and it broke a few normal use cases; since we don't have
time to fix it, we'll try again after this week's minor releases.
Reported-by: Rushabh Lathia
Discussion: https://postgr.es/m/CAGPqQf0iQV=PPOv2Btog9J9AwOQp6HmuVd6SbGTR_v3Zp2XT1w@mail.gmail.com
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/t/002_pg_dump.pl
Add tests for error message generation in partition tuple routing
commit : 91248608a61d5504f8ac46534136de9b3717fed2
author : Michael Paquier <michael@paquier.xyz>
date : Mon, 6 May 2019 21:44:24 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Mon, 6 May 2019 21:44:24 +0900
This adds extra tests for the error message generated for partition
tuple routing in the executor, using more than three levels of
partitioning including partitioned tables with no partitions. These
tests have been added to fix CVE-2019-10129 on REL_11_STABLE. HEAD has
no active bugs in this area, but it lacked coverage.
Author: Michael Paquier
Reviewed-by: Noah Misch
Security: CVE-2019-10129
M src/test/regress/expected/insert.out
M src/test/regress/sql/insert.sql
Use checkAsUser for selectivity estimator checks, if it's set.
commit : a0905056fd6b0927dd33f185adc9e7503515fc0d
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Mon, 6 May 2019 11:54:32 +0100
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Mon, 6 May 2019 11:54:32 +0100
In examine_variable() and examine_simple_variable(), when checking the
user's table and column privileges to determine whether to grant
access to the pg_statistic data, use checkAsUser for the privilege
checks, if it's set. This will be the case if we're accessing the
table via a view, to indicate that we should perform privilege checks
as the view owner rather than the current user.
This change makes this planner check consistent with the check in the
executor, so the planner will be able to make use of statistics if the
table is accessible via the view. This fixes a performance regression
introduced by commit e2d4ef8de8, which affects queries against
non-security barrier views in the case where the user doesn't have
privileges on the underlying table, but the view owner does.
Note that it continues to provide the same safeguards controlling
access to pg_statistic for direct table access (in which case
checkAsUser won't be set) and for security barrier views, because of
the nearby checks on rte->security_barrier and rte->securityQuals.
Back-patch to all supported branches because e2d4ef8de8 was.
Dean Rasheed, reviewed by Jonathan Katz and Stephen Frost.
M src/backend/utils/adt/selfuncs.c
M src/test/regress/expected/privileges.out
M src/test/regress/sql/privileges.sql
Fix security checks for selectivity estimation functions with RLS.
commit : 1aebfbea83c4a3e1a0aba4b0910135dc5a45666c
author : Dean Rasheed <dean.a.rasheed@gmail.com>
date : Mon, 6 May 2019 11:38:43 +0100
committer: Dean Rasheed <dean.a.rasheed@gmail.com>
date : Mon, 6 May 2019 11:38:43 +0100
In commit e2d4ef8de8, security checks were added to prevent
user-supplied operators from running over data from pg_statistic
unless the user has table or column privileges on the table, or the
operator is leakproof. For a table with RLS, however, checking for
table or column privileges is insufficient, since that does not
guarantee that the user has permission to view all of the column's
data.
Fix this by also checking for securityQuals on the RTE, and insisting
that the operator be leakproof if there are any. Thus the
leakproofness check will only be skipped if there are no securityQuals
and the user has table or column privileges on the table -- i.e., only
if we know that the user has access to all the data in the column.
Back-patch to 9.5 where RLS was added.
Dean Rasheed, reviewed by Jonathan Katz and Stephen Frost.
Security: CVE-2019-10130
M src/backend/utils/adt/selfuncs.c
M src/test/regress/expected/rowsecurity.out
M src/test/regress/sql/rowsecurity.sql
Bring pg_nextoid()'s error messages into line with message style guide.
commit : bd5e8b627bae9e394352a388d2ad30465eafea2c
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 May 2019 17:06:53 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 May 2019 17:06:53 -0400
Noticed while reviewing nearby code. Given all the disclaimers about
this not being meant as user-facing code, I wonder whether we should
make these non-translatable? But in any case there's little excuse
for them not to be good English.
M src/backend/catalog/catalog.c
Fix style violations in syscache lookups.
commit : 9691aa72e2a7fb146ac759e1f8a8b04962128cc0
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 May 2019 13:10:07 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 May 2019 13:10:07 -0400
Project style is to check the success of SearchSysCacheN and friends
by applying HeapTupleIsValid to the result. A tiny minority of calls
creatively did it differently. Bring them into line with the rest.
This is just cosmetic, since HeapTupleIsValid is indeed just a null
check at the moment ... but that may not be true forever, and in any
case it puts a mental burden on readers who may wonder why these
call sites are not like the rest.
Back-patch to v11 just to keep the branches in sync. (The bulk of these
errors seem to have originated in v11 or v12, though a few are old.)
Per searching to see if anyplace else had made the same error
repaired in 62148c352.
M src/backend/catalog/partition.c
M src/backend/catalog/pg_publication.c
M src/backend/commands/indexcmds.c
M src/backend/commands/opclasscmds.c
M src/backend/commands/operatorcmds.c
M src/backend/commands/statscmds.c
M src/backend/commands/tablecmds.c
M src/backend/optimizer/util/appendinfo.c
M src/backend/optimizer/util/plancat.c
Add check for syscache lookup failure in update_relispartition().
commit : 62148c3520b562e518f17134b22120bab0cb113b
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 May 2019 12:44:32 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Sun, 5 May 2019 12:44:32 -0400
Omitted in commit 05b38c7e6 (though it looks like the original blame
belongs to 9e9befac4). A failure is admittedly unlikely, but if it
did happen, SIGSEGV is not the approved method of reporting it.
Per Coverity. Back-patch to v11 where the broken code originated.
M src/backend/commands/indexcmds.c
Fix set of issues with memory-allocation system calls in frontend code
commit : 84e4570da9230d45022ef77f98b560f26eaf6916
author : Michael Paquier <michael@paquier.xyz>
date : Sat, 4 May 2019 16:32:19 +0900
committer: Michael Paquier <michael@paquier.xyz>
date : Sat, 4 May 2019 16:32:19 +0900
Like the backend, the frontend has wrappers on top of malloc() and such
whose use is recommended. Particularly, it is possible to do memory
allocation without issuing an error. Some binaries missed the use of
those wrappers, so let's fix the gap for consistency.
This also fixes two latent bugs:
- In pg_dump/pg_dumpall when parsing an ACL item, on an out-of-memory
error for strdup(), the code considered the failure as a ACL parsing
problem instead of an actual OOM.
- In pg_waldump, an OOM when building the target directory string would
cause a crash.
Author: Daniel Gustafsson
Discussion: https://postgr.es/m/gY0y9xenfoBPc-Tufsr2Zg-MmkrJslm0Tw_CMg4p_j58-k_PXNC0klMdkKQkg61BkXC9_uWo-DcUzfxnHqpkpoR5jjVZrPHqKYikcHIiONhg=@yesql.se
M src/bin/pg_ctl/pg_ctl.c
M src/bin/pg_dump/dumputils.c
M src/bin/pg_test_fsync/pg_test_fsync.c
M src/bin/pg_waldump/pg_waldump.c
M src/bin/psql/large_obj.c
MSVC: Build ~35% faster by calling dumpbin just once per directory.
commit : 34ff542a71f8e8e768b24d40548dec4be0c707c3
author : Noah Misch <noah@leadboat.com>
date : Fri, 3 May 2019 21:56:47 -0700
committer: Noah Misch <noah@leadboat.com>
date : Fri, 3 May 2019 21:56:47 -0700
Peifeng Qiu
Discussion: https://postgr.es/m/CABmtVJiKXQjast0dQD-8KAtfm8XmyYxo-4Dc7+M+fBr8JRTqkw@mail.gmail.com
M src/tools/msvc/gendef.pl
Suppress compiler warning in non-SSL, non-assert builds.
commit : 726cc4242a2f766c8280a72ef7c8418965d139c8
author : Noah Misch <noah@leadboat.com>
date : Fri, 3 May 2019 21:56:46 -0700
committer: Noah Misch <noah@leadboat.com>
date : Fri, 3 May 2019 21:56:46 -0700
Jeff Janes, reviewed by Michael Paquier.
Discussion: https://postgr.es/m/CAMkU=1x8taZfsbPkv_MsWbTtzibW_yQHXoMhF_DTtm=z2hVHDg@mail.gmail.com
M contrib/pgcrypto/imath.c
Correct more obsolete nbtree page split comments.
commit : 7b37f4b02e11813b3cd9f7086149ba962a91e03c
author : Peter Geoghegan <pg@bowt.ie>
date : Fri, 3 May 2019 13:34:45 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Fri, 3 May 2019 13:34:45 -0700
Commit 3f342839 corrected obsolete comments about buffer locks at the
main _bt_insert_parent() call site, but missed similar obsolete comments
above _bt_insert_parent() itself. Both sets of comments were rendered
obsolete by commit 40dae7ec537, which made the nbtree page split
algorithm more robust. Fix the comments that were missed the first time
around now.
In passing, refine a related _bt_insert_parent() comment about
re-finding the parent page to insert new downlink.
M src/backend/access/nbtree/nbtinsert.c
Doc: remove obsolete comment about per-branch documentation.
commit : 8309eae499d6782bfc5e81f4d1cfcbf8e3fc8f5d
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 May 2019 12:32:06 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 May 2019 12:32:06 -0400
I should have removed this in a0b762626, but forgot.
M doc/src/sgml/release.sgml
Remove RelationSetIndexList().
commit : f884dca4959f64bd47e78102d1dadd2c77d49201
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 May 2019 10:26:14 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Fri, 3 May 2019 10:26:14 -0400
In the wake of commit f912d7dec, RelationSetIndexList isn't used any
more. It was always a horrid wart, so getting rid of it is very nice.
We can also convert rd_indexvalid back to a plain boolean.
Discussion: https://postgr.es/m/28926.1556664156@sss.pgh.pa.us
M src/backend/utils/cache/relcache.c
M src/include/utils/rel.h
M src/include/utils/relcache.h
Fix reindexing of pg_class indexes some more.
commit : f912d7dec29341d55315fccef8dc3fdfd068c6e3
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 2 May 2019 19:11:28 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Thu, 2 May 2019 19:11:28 -0400
Commits 3dbb317d3 et al failed under CLOBBER_CACHE_ALWAYS testing.
Investigation showed that to reindex pg_class_oid_index, we must
suppress accesses to the index (via SetReindexProcessing) before we call
RelationSetNewRelfilenode, or at least before we do CommandCounterIncrement
therein; otherwise, relcache reloads happening within the CCI may try to
fetch pg_class rows using the index's new relfilenode value, which is as
yet an empty file.
Of course, the point of 3dbb317d3 was that that ordering didn't work
either, because then RelationSetNewRelfilenode's own update of the index's
pg_class row cannot access the index, should it need to.
There are various ways we might have got around that, but Andres Freund
came up with a brilliant solution: for a mapped index, we can really just
skip the pg_class update altogether. The only fields it was actually
changing were relpages etc, but it was just setting them to zeroes which
is useless make-work. (Correct new values will be installed at the end
of index build.) All pg_class indexes are mapped and probably always will
be, so this eliminates the problem by removing work rather than adding it,
always a pleasant outcome. Having taught RelationSetNewRelfilenode to do
it that way, we can revert the code reordering in reindex_index. (But
I left the moved setup code where it was; there seems no reason why it
has to run without use of the old index. If you're trying to fix a
busted pg_class index, you'll have had to disable system index use
altogether to get this far.)
Moreover, this means we don't need RelationSetIndexList at all, because
reindex_relation's hacking to make "REINDEX TABLE pg_class" work is
likewise now unnecessary. We'll leave that code in place in the back
branches, but a follow-on patch will remove it in HEAD.
In passing, do some minor cleanup for commit 5c1560606 (in HEAD only),
notably removing a duplicate newrnode assignment.
Patch by me, using a core idea due to Andres Freund. Back-patch to all
supported branches, as 3dbb317d3 was.
Discussion: https://postgr.es/m/28926.1556664156@sss.pgh.pa.us
M src/backend/catalog/index.c
M src/backend/utils/cache/relcache.c
heap_prepare_freeze_tuple: Simplify coding
commit : 2bf372a4ae26337ee61cf7a82081cf4bed05182d
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 2 May 2019 16:13:48 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Thu, 2 May 2019 16:13:48 -0400
Commit d2599ecfcc74 introduced some contorted, confused code around:
readers would think that it's possible for HeapTupleHeaderGetXmin return
a non-frozen value for some frozen tuples, which would be disastrous.
There's no actual bug, but it seems better to make it clearer.
Per gripe from Tom Lane and Andres Freund.
Discussion: https://postgr.es/m/30116.1555430496@sss.pgh.pa.us
M src/backend/access/heap/heapam.c
Fix nbtsort.c's page space accounting.
commit : 6dd86c269d5b9a176f6c9f67ea61cc17fef9d860
author : Peter Geoghegan <pg@bowt.ie>
date : Thu, 2 May 2019 12:33:35 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Thu, 2 May 2019 12:33:35 -0700
Commit dd299df8189, which made heap TID a tiebreaker nbtree index
column, introduced new rules on page space management to make suffix
truncation safe. In general, suffix truncation needs to have a small
amount of extra space available on the new left page when splitting a
leaf page. This is needed in case it turns out that truncation cannot
even "truncate away the heap TID column", resulting in a
larger-than-firstright leaf high key with an explicit heap TID
representation.
Despite all this, CREATE INDEX/nbtsort.c did not account for the
possible need for extra heap TID space on leaf pages when deciding
whether or not a new item could fit on current page. This could lead to
"failed to add item to the index page" errors when CREATE
INDEX/nbtsort.c tried to finish off a leaf page that lacked space for a
larger-than-firstright leaf high key (it only had space for firstright
tuple, which was just short of what was needed following "truncation").
Several conditions needed to be met all at once for CREATE INDEX to
fail. The problem was in the hard limit on what will fit on a page,
which tends to be masked by the soft fillfactor-wise limit. The easiest
way to recreate the problem seems to be a CREATE INDEX on a low
cardinality text column, with tuples that are of non-uniform width,
using a fillfactor of 100.
To fix, bring nbtsort.c in line with nbtsplitloc.c, which already
pessimistically assumes that all leaf page splits will have high keys
that have a heap TID appended.
Reported-By: Andreas Joseph Krogh
Discussion: https://postgr.es/m/VisenaEmail.c5.3ee7fe277d514162.16a6d785bea@tc7-visena
M src/backend/access/nbtree/nbtsort.c
Fix some problems with VACUUM (INDEX_CLEANUP FALSE).
commit : dd69597988859c51131e0cbff3e30432db4259e1
author : Robert Haas <rhaas@postgresql.org>
date : Thu, 2 May 2019 10:07:13 -0400
committer: Robert Haas <rhaas@postgresql.org>
date : Thu, 2 May 2019 10:07:13 -0400
The new nleft_dead_tuples and nleft_dead_itemids fields are confusing
and do not seem like the correct way forward. One of them is tested
via an assertion that can fail, as it has already done on buildfarm
member topminnow. Remove the assertion and the fields.
Change the logic for the case where a tuple is not initially pruned
by heap_page_prune but later diagnosed HEAPTUPLE_DEAD by
HeapTupleSatisfiesVacuum. Previously, tupgone = true was set in
that case, which leads to treating the tuple as one that will be
removed. In a normal vacuum, that's OK, because we'll remove
index entries for it and then the second heap pass will remove the
tuple itself, but when index cleanup is disabled, those things
don't happen, so we must instead treat it as a recently-dead
tuple that we have voluntarily chosen to keep.
Report and analysis by Tom Lane. This patch loosely based on one
from Masahiko Sawada, but I changed most of it.
M src/backend/access/heap/vacuumlazy.c
doc: clarify behavior of pg_upgrade's clone mode
commit : 26950273dc27ec7775029cffe1140165f942325d
author : Bruce Momjian <bruce@momjian.us>
date : Wed, 1 May 2019 09:09:28 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Wed, 1 May 2019 09:09:28 -0400
Be more precise about the benefits of using clone mode.
M doc/src/sgml/ref/pgupgrade.sgml
Fix union for pgstat message types
commit : 659e53498c3c04e4f400323c02bef98fe8d13ec8
author : Magnus Hagander <magnus@hagander.net>
date : Wed, 1 May 2019 12:30:44 +0200
committer: Magnus Hagander <magnus@hagander.net>
date : Wed, 1 May 2019 12:30:44 +0200
The message type for temp files and for checksum failures were missing
from the union. Due to the coding style used there was no compiler error
when this happend. So change the code to actively use the union thereby
producing a compiler error if the same mistake happens again, suggested
by Tom Lane.
Author: Julien Rouhaud
Reported-By: Tomas Vondra
Discussion: https://postgr.es/m/20190430163328.zd4rrlnbvgaqlcdz@development
M src/backend/postmaster/pgstat.c
M src/include/pgstat.h
Run catalog reindexing test from 3dbb317d32 serially, to avoid deadlocks.
commit : 809c9b48f4bdd11dfc088f6d0b9a6c57936c32ca
author : Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 17:45:32 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 17:45:32 -0700
The tests turn out to cause deadlocks in some circumstances. Fairly
reproducibly so with -DRELCACHE_FORCE_RELEASE
-DCATCACHE_FORCE_RELEASE. Some of the deadlocks may be hard to fix
without disproportionate measures, but others probably should be fixed
- but not in 12.
We discussed removing the new tests until we can fix the issues
underlying the deadlocks, but results from buildfarm animal
markhor (which runs with CLOBBER_CACHE_ALWAYS) indicates that there
might be a more severe, as of yet undiagnosed, issue (including on
stable branches) with reindexing catalogs. The failure is:
ERROR: could not read block 0 in file "base/16384/28025": read only 0 of 8192 bytes
Therefore it seems advisable to keep the tests.
It's not certain that running the tests in isolation removes the risk
of deadlocks. It's possible that additional locks are needed to
protect against a concurrent auto-analyze or such.
Per discussion with Tom Lane.
Discussion: https://postgr.es/m/28926.1556664156@sss.pgh.pa.us
Backpatch: 9.4-, like 3dbb317d3
M src/test/regress/expected/create_index.out
A src/test/regress/expected/reindex_catalog.out
M src/test/regress/parallel_schedule
M src/test/regress/serial_schedule
M src/test/regress/sql/create_index.sql
A src/test/regress/sql/reindex_catalog.sql
Fix unused variable compiler warning in !debug builds.
commit : 4b40d40b30ae04ba524cd410f14e64ae4425a180
author : Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 17:45:32 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 17:45:32 -0700
Introduced in 3dbb317d3. Fix by using the new local variable in more
places.
Reported-By: Bruce Momjian (off-list)
Backpatch: 9.4-, like 3dbb317d3
M src/backend/catalog/indexing.c
docs: Fix small copy & paste mistake.
commit : b06a354e381d30e13cef28904bb923896aa4719b
author : Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 16:18:35 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 16:18:35 -0700
Author: Justin Pryzby
Discussion: https://postgr.es/m/20190418005115.r4mat75wvlski3ij@alap3.anarazel.de
M doc/src/sgml/ref/insert.sgml
Improve comment spelling and style in llvmjit_deform.c.
commit : a0b5bb6e026a3acf739843b744f3b14d4093450a
author : Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 16:13:54 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 16:13:54 -0700
Author: Justin Pryzby
Discussion:
https://postgr.es/m/20190408141828.GE10080@telsasoft.com
https://postgr.es/m/20181127184133.GM10913@telsasoft.com
M src/backend/jit/llvm/llvmjit_deform.c
Improve code inferring length of bitmap for JITed tuple deforming.
commit : 3a48005b0049d69b4376e6ae386479ae3d255a11
author : Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 15:55:07 -0700
committer: Andres Freund <andres@anarazel.de>
date : Tue, 30 Apr 2019 15:55:07 -0700
While discussing comment improvements (see next commit) by Justin
Pryzby, Tom complained about a few details of the logic to infer the
length of the NULL bitmap when building the JITed tuple deforming
function. That bitmap allows to avoid checking the tuple header's
natts, a check which often causes a pipeline stall
Improvements:
a) As long as missing columns aren't taken into account, we can
continue to infer the length of the NULL bitmap from NOT NULL
columns following it. Previously we stopped at the first missing
column. It's unlikely to matter much in practice, but the
alternative would have been to document why we stop.
b) For robustness reasons it seems better to also check against
attisdropped - RemoveAttributeById() sets attnotnull to false, but
an additional check is trivial.
c) Improve related comments
Discussion: https://postgr.es/m/20637.1555957068@sss.pgh.pa.us
Backpatch: -
M src/backend/jit/llvm/llvmjit_deform.c
Clean up handling of constraint_exclusion and enable_partition_pruning.
commit : e03ff739695cb731956763355e8e0f38c6905008
author : Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 30 Apr 2019 15:03:35 -0400
committer: Tom Lane <tgl@sss.pgh.pa.us>
date : Tue, 30 Apr 2019 15:03:35 -0400
The interaction of these parameters was a bit confused/confusing,
and in fact v11 entirely misses the opportunity to apply partition
constraints when a partition is accessed directly (rather than
indirectly from its parent).
In HEAD, establish the principle that enable_partition_pruning controls
partition pruning and nothing else. When accessing a partition via its
parent, we do partition pruning (if enabled by enable_partition_pruning)
and then there is no need to consider partition constraints in the
constraint_exclusion logic. When accessing a partition directly, its
partition constraints are applied by the constraint_exclusion logic,
only if constraint_exclusion = on.
In v11, we can't have such a clean division of these GUCs' effects,
partly because we don't want to break compatibility too much in a
released branch, and partly because the clean coding requires
inheritance_planner to have applied partition pruning to a partitioned
target table, which it doesn't in v11. However, we can tweak things
enough to cover the missed case, which seems like a good idea since
it's potentially a performance regression from v10. This patch keeps
v11's previous behavior in which enable_partition_pruning overrides
constraint_exclusion for an inherited target table, though.
In HEAD, also teach relation_excluded_by_constraints that it's okay to use
inheritable constraints when trying to prune a traditional inheritance
tree. This might not be thought worthy of effort given that that feature
is semi-deprecated now, but we have enough infrastructure that it only
takes a couple more lines of code to do it correctly.
Amit Langote and Tom Lane
Discussion: https://postgr.es/m/9813f079-f16b-61c8-9ab7-4363cab28d80@lab.ntt.co.jp
Discussion: https://postgr.es/m/29069.1555970894@sss.pgh.pa.us
M doc/src/sgml/config.sgml
M doc/src/sgml/ddl.sgml
M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/util/plancat.c
M src/test/regress/expected/partition_prune.out
M src/test/regress/sql/partition_prune.sql
doc: improve PG 12 to_timestamp()/to_date() wording
commit : ad23adc5a169b114f9ff325932cbf2ce1c5e69c1
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 30 Apr 2019 14:06:57 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 30 Apr 2019 14:06:57 -0400
M doc/src/sgml/func.sgml
doc: move "only" to a more appropriate place in the sentence
commit : 345473862571d5b2c63849f6472828bdc5b49320
author : Bruce Momjian <bruce@momjian.us>
date : Tue, 30 Apr 2019 13:44:31 -0400
committer: Bruce Momjian <bruce@momjian.us>
date : Tue, 30 Apr 2019 13:44:31 -0400
M doc/src/sgml/func.sgml
Message style fixes
commit : 9f8b717a80c59e4a8e8091a8ff6c6f7666a69c33
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 30 Apr 2019 10:00:38 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Tue, 30 Apr 2019 10:00:38 -0400
M src/backend/access/table/tableamapi.c
M src/backend/access/transam/twophase.c
M src/backend/commands/indexcmds.c
M src/backend/commands/tablecmds.c
M src/backend/utils/misc/guc.c
M src/test/regress/output/tablespace.source
Widen tuple counter variables from long to int64
commit : 9a83afecb7ec6e828b7dbef3133f3dd8b0b4dddb
author : Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 29 Apr 2019 14:15:19 -0400
committer: Alvaro Herrera <alvherre@alvh.no-ip.org>
date : Mon, 29 Apr 2019 14:15:19 -0400
Mistake in ab0dfc961b6a; progress reporting would have wrapped around
for indexes created with more than 2^31 tuples.
Reported-by: Peter Geoghegan
Discussion: https://postgr.es/m/CAH2-Wz=WbNxc5ob5NJ9yqo2RMJ0q4HXDS30GVCobeCvC9A1L9A@mail.gmail.com
M src/backend/access/hash/hashsort.c
M src/backend/access/nbtree/nbtsort.c
Fix potential assertion failure when reindexing a pg_class index.
commit : 3dbb317d32f4f084ef7badaed8ef36f5c9b85fe6
author : Andres Freund <andres@anarazel.de>
date : Mon, 29 Apr 2019 19:42:04 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 29 Apr 2019 19:42:04 -0700
When reindexing individual indexes on pg_class it was possible to
either trigger an assertion failure:
TRAP: FailedAssertion("!(!ReindexIsProcessingIndex(((index)->rd_id)))
That's because reindex_index() called SetReindexProcessing() - which
enables an asserts ensuring no index insertions happen into the index
- before calling RelationSetNewRelfilenode(). That not correct for
indexes on pg_class, because RelationSetNewRelfilenode() updates the
relevant pg_class row, which needs to update the indexes.
The are two reasons this wasn't noticed earlier. Firstly the bug
doesn't trigger when reindexing all of pg_class, as reindex_relation
has code "hiding" all yet-to-be-reindexed indexes. Secondly, the bug
only triggers when the the update to pg_class doesn't turn out to be a
HOT update - otherwise there's no index insertion to trigger the
bug. Most of the time there's enough space, making this bug hard to
trigger.
To fix, move RelationSetNewRelfilenode() to before the
SetReindexProcessing() (and, together with some other code, to outside
of the PG_TRY()).
To make sure the error checking intended by SetReindexProcessing() is
more robust, modify CatalogIndexInsert() to check
ReindexIsProcessingIndex() even when the update is a HOT update.
Also add a few regression tests for REINDEXing of system catalogs.
The last two improvements would have prevented some of the issues
fixed in 5c1560606dc4c from being introduced in the first place.
Reported-By: Michael Paquier
Diagnosed-By: Tom Lane and Andres Freund
Author: Andres Freund
Reviewed-By: Tom Lane
Discussion: https://postgr.es/m/20190418011430.GA19133@paquier.xyz
Backpatch: 9.4-, the bug is present in all branches
M contrib/test_decoding/expected/rewrite.out
M contrib/test_decoding/sql/rewrite.sql
M src/backend/catalog/index.c
M src/backend/catalog/indexing.c
M src/test/regress/expected/create_index.out
M src/test/regress/sql/create_index.sql
Fix several recently introduced issues around handling new relation forks.
commit : 5c1560606dc4c73993fb07f0176b5ec6c515a1b1
author : Andres Freund <andres@anarazel.de>
date : Mon, 29 Apr 2019 19:28:05 -0700
committer: Andres Freund <andres@anarazel.de>
date : Mon, 29 Apr 2019 19:28:05 -0700
Most of these stem from d25f519107 "tableam: relation creation, VACUUM
FULL/CLUSTER, SET TABLESPACE.".
1) To pass data to the relation_set_new_filenode()
RelationSetNewRelfilenode() was made to update RelationData.rd_rel
directly. That's not OK however, as it makes the relcache entries
temporarily inconsistent. Which among other scenarios is a problem
if a REINDEX targets an index on pg_class - the
CatalogTupleUpdate() in RelationSetNewRelfilenode(). Presumably
that was introduced because other places in the code do so - while
those aren't "good practice" they don't appear to be actively
buggy (e.g. because system tables may not be targeted).
I (Andres) should have caught this while reviewing and signficantly
evolving the code in that commit, mea culpa.
Fix that by instead passing in the new RelFileNode as separate
argument to relation_set_new_filenode() and rely on the relcache to
update the catalog entry. Also revert that the
RelationMapUpdateMap() call was changed to immediate, and undo some
other more unnecessary changes.
2) Document that the relation_set_new_filenode cannot rely on the
whole relcache entry to be valid. It might be worthwhile to
refactor the code to never have to rely on that, but given the way
heap_create() is currently coded, that'd be a large change.
3) ATExecSetTableSpace() shouldn't do FlushRelationBuffers() itself. A
table AM might not use shared buffers at all. Move to
index_copy_data() and heapam_relation_copy_data().
4) heapam_relation_set_new_filenode() previously sometimes accessed
rel->rd_rel->relpersistence rather than the `persistence`
argument. Code movement mistake.
5) Previously heapam_relation_set_new_filenode() re-opened the smgr
relation to create the init for, if necesary. Instead have
RelationCreateStorage() return the SMgrRelation and use it to
create the init fork.
6) Add a note about the danger of modifying the relcache directly to
ATExecSetTableSpace() - it's currently not a bug because there's a
check ERRORing for catalog tables.
Regression tests and assertion improvements that together trigger the
bug described in 1) will be added in a later commit, as there is a
related bug on all branches.
Reported-By: Michael Paquier
Diagnosed-By: Tom Lane and Andres Freund
Author: Andres Freund
Reviewed-By: Tom Lane
Discussion: https://postgr.es/m/20190418011430.GA19133@paquier.xyz
M src/backend/access/heap/heapam_handler.c
M src/backend/catalog/heap.c
M src/backend/catalog/storage.c
M src/backend/commands/tablecmds.c
M src/backend/utils/cache/relcache.c
M src/include/access/tableam.h
M src/include/catalog/storage.h
M src/include/catalog/storage_xlog.h
Remove obsolete _bt_insert_parent() comment.
commit : 9ee7414ed0435d8946d040eb523824f2d71e2418
author : Peter Geoghegan <pg@bowt.ie>
date : Mon, 29 Apr 2019 14:14:38 -0700
committer: Peter Geoghegan <pg@bowt.ie>
date : Mon, 29 Apr 2019 14:14:38 -0700
Remove a comment that refers to a coding practice that was fully removed
by commit a8b8f4db, which introduced MarkBufferDirty(). It looks like
the comment was even obsolete before then, since it concerns
write-ordering dependencies with synchronous buffer writes.