Stamp 11.2.
commit : 6cd404b344f7e27f4d64555bb133f18a758fe851
author : Tom Lane <[email protected]>
date : Mon, 11 Feb 2019 16:17:27 -0500
committer: Tom Lane <[email protected]>
date : Mon, 11 Feb 2019 16:17:27 -0500
M configure
M configure.in
M doc/bug.template
M src/include/pg_config.h.win32
M src/interfaces/libpq/libpq.rc.in
M src/port/win32ver.rc
Last-minute updates for release notes.
commit : 6c9356080c2060bcd4a6cef520aa3d8121940ee7
author : Tom Lane <[email protected]>
date : Mon, 11 Feb 2019 12:05:49 -0500
committer: Tom Lane <[email protected]>
date : Mon, 11 Feb 2019 12:05:49 -0500
M doc/src/sgml/release-11.sgml
Translation updates
commit : 352f9b57cfdf3e8f871474223975ee2c6b725bf7
author : Peter Eisentraut <[email protected]>
date : Mon, 11 Feb 2019 14:31:57 +0100
committer: Peter Eisentraut <[email protected]>
date : Mon, 11 Feb 2019 14:31:57 +0100
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 2cd47eeb832ed1bb1cbfff285cfc921ca4d07a9d
M src/backend/po/de.po
M src/backend/po/fr.po
M src/backend/po/ja.po
M src/backend/po/ru.po
M src/backend/po/sv.po
M src/backend/po/tr.po
M src/bin/initdb/po/de.po
M src/bin/initdb/po/fr.po
M src/bin/initdb/po/he.po
M src/bin/initdb/po/ru.po
M src/bin/initdb/po/sv.po
M src/bin/initdb/po/tr.po
M src/bin/pg_basebackup/po/he.po
M src/bin/pg_config/po/tr.po
M src/bin/pg_controldata/po/tr.po
M src/bin/pg_ctl/po/he.po
M src/bin/pg_ctl/po/ru.po
M src/bin/pg_dump/po/he.po
M src/bin/pg_dump/po/ru.po
M src/bin/pg_dump/po/sv.po
M src/bin/pg_dump/po/tr.po
M src/bin/pg_resetwal/po/tr.po
M src/bin/pg_rewind/po/de.po
M src/bin/pg_rewind/po/fr.po
M src/bin/pg_rewind/po/ja.po
M src/bin/pg_rewind/po/ru.po
M src/bin/pg_rewind/po/sv.po
M src/bin/pg_test_fsync/po/tr.po
M src/bin/pg_upgrade/po/de.po
M src/bin/pg_upgrade/po/fr.po
M src/bin/pg_upgrade/po/ru.po
M src/bin/pg_upgrade/po/sv.po
M src/bin/pg_verify_checksums/po/ru.po
M src/bin/psql/po/es.po
M src/bin/psql/po/fr.po
M src/bin/psql/po/he.po
M src/bin/psql/po/ja.po
M src/bin/psql/po/ru.po
M src/bin/scripts/po/he.po
M src/bin/scripts/po/ru.po
M src/interfaces/ecpg/ecpglib/po/ru.po
M src/interfaces/ecpg/preproc/po/tr.po
M src/interfaces/libpq/po/he.po
M src/interfaces/libpq/po/ru.po
M src/pl/plpgsql/src/po/de.po
M src/pl/plpgsql/src/po/fr.po
M src/pl/plpgsql/src/po/ru.po
M src/pl/plpgsql/src/po/sv.po
M src/pl/plpython/po/vi.po
Adjust error message
commit : 12055c8f643afa5ed70d17acc7782c21299ffb69
author : Peter Eisentraut <[email protected]>
date : Mon, 11 Feb 2019 10:31:36 +0100
committer: Peter Eisentraut <[email protected]>
date : Mon, 11 Feb 2019 10:31:36 +0100
We usually don't use "namespace" in user-facing error messages. Also,
in master this was replaced by another error message referring to
"temporary objects", so we might as well use that here to avoid
introducing too many variants.
Discussion: https://www.postgresql.org/message-id/[email protected]
M src/backend/access/transam/xact.c
M src/test/modules/test_extensions/expected/test_extensions.out
M src/test/regress/expected/temp.out
Fix indexable-row-comparison logic to account for covering indexes.
commit : eb68d71f99e945c89bbb1190086237be65ad784c
author : Tom Lane <[email protected]>
date : Sun, 10 Feb 2019 22:51:33 -0500
committer: Tom Lane <[email protected]>
date : Sun, 10 Feb 2019 22:51:33 -0500
indxpath.c needs a good deal more attention for covering indexes than
it's gotten. But so far as I can tell, the only really awful breakage
is in expand_indexqual_rowcompare (nee adjust_rowcompare_for_index),
which was only half fixed in c266ed31a. The other problems aren't
bad enough to take the risk of a just-before-wrap fix.
The problem here is that if the leading column of a row comparison
matches an index (allowing this code to be reached), and some later
column doesn't match the index, it'll nonetheless believe that that
column matches the first included index column. Typically that'll
lead to an error like "operator M is not a member of opfamily N" as
a result of fetching a garbage opfamily OID. But with enough bad
luck, maybe a broken plan would be generated.
Discussion: https://postgr.es/m/[email protected]
M src/backend/optimizer/path/indxpath.c
M src/test/regress/expected/index_including.out
M src/test/regress/sql/index_including.sql
Release notes for 11.2, 10.7, 9.6.12, 9.5.16, 9.4.21.
commit : 2eebda274fa97e5fee6a6001a07eed079e5be69f
author : Tom Lane <[email protected]>
date : Sun, 10 Feb 2019 15:44:04 -0500
committer: Tom Lane <[email protected]>
date : Sun, 10 Feb 2019 15:44:04 -0500
M doc/src/sgml/release-11.sgml
Second draft of back-branch release notes.
commit : 1f67ff8ce55a3397733f3b18371865f145873143
author : Tom Lane <[email protected]>
date : Sun, 10 Feb 2019 14:02:26 -0500
committer: Tom Lane <[email protected]>
date : Sun, 10 Feb 2019 14:02:26 -0500
Add items for the weekend's commits. Add corrections from
Peter Geoghegan, Amit Kapila, and Alexander Kuzmenkov.
Some copy-editing of my own too.
M doc/src/sgml/release-11.sgml
Fix trigger drop procedure
commit : cc126b45ea5c5e408b01ff4fb09a974450e11025
author : Alvaro Herrera <[email protected]>
date : Sun, 10 Feb 2019 10:00:11 -0300
committer: Alvaro Herrera <[email protected]>
date : Sun, 10 Feb 2019 10:00:11 -0300
After commit 123cc697a8eb, we remove redundant FK action triggers during
partition ATTACH by merely deleting the catalog tuple, but that's wrong:
it should use performDeletion() instead. Repair, and make the comments
more explicit.
Per code review from Tom Lane.
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/tablecmds.c
Solve cross-version-upgrade testing problem induced by 1fb57af92.
commit : ee6370978fd921c22ec8bf2239ad4d30ae126fed
author : Tom Lane <[email protected]>
date : Sat, 9 Feb 2019 21:02:06 -0500
committer: Tom Lane <[email protected]>
date : Sat, 9 Feb 2019 21:02:06 -0500
Renaming varchar_transform to varchar_support had a side effect
I hadn't foreseen: the core regression tests leave around a
transform object that relies on that function, so the name
change breaks cross-version upgrade tests, because the name
used in the older branches doesn't match.
Since the dependency on varchar_transform was chosen with the
aid of a dartboard anyway (it would surely not work as a
language transform support function), fix by just choosing
a different random builtin function with the right signature.
Also add some comments explaining why this isn't horribly unsafe.
I chose to make the same substitution in a couple of other
copied-and-pasted test cases, for consistency, though those
aren't directly contributing to the testing problem.
Per buildfarm. Back-patch, else it doesn't fix the problem.
M src/bin/pg_dump/t/002_pg_dump.pl
M src/test/modules/test_ddl_deparse/expected/create_transform.out
M src/test/modules/test_ddl_deparse/sql/create_transform.sql
M src/test/regress/expected/object_address.out
M src/test/regress/sql/object_address.sql
Repair unsafe/unportable snprintf usage in pg_restore.
commit : ef9bf359369b4dfaceb859941c3898b5ce1decf6
author : Tom Lane <[email protected]>
date : Sat, 9 Feb 2019 19:45:38 -0500
committer: Tom Lane <[email protected]>
date : Sat, 9 Feb 2019 19:45:38 -0500
warn_or_exit_horribly() was blithely passing a potentially-NULL
string pointer to a %s format specifier. That works (at least
to the extent of not crashing) on some platforms, but not all,
and since we switched to our own snprintf.c it doesn't work
for us anywhere.
Of the three string fields being handled this way here, I think
that only "owner" is supposed to be nullable ... but considering
that this is error-reporting code, it has very little business
assuming anything, so put in defenses for all three.
Per a crash observed on buildfarm member crake and then
reproduced here. Because of the portability aspect,
back-patch to all supported versions.
M src/bin/pg_dump/pg_backup_archiver.c
Call set_rel_pathlist_hook before generate_gather_paths, not after.
commit : 027b5a300a9e9b407f465f0264cb88305eb0539d
author : Tom Lane <[email protected]>
date : Sat, 9 Feb 2019 11:41:09 -0500
committer: Tom Lane <[email protected]>
date : Sat, 9 Feb 2019 11:41:09 -0500
The previous ordering of these steps satisfied the nominal requirement
that set_rel_pathlist_hook could editorialize on the whole set of Paths
constructed for a base relation. In practice, though, trying to change
the set of partial paths was impossible. Adding one didn't work because
(a) it was too late to be included in Gather paths made by the core code,
and (b) calling add_partial_path after generate_gather_paths is unsafe,
because it might try to delete a path it thinks is dominated, but that
is already embedded in some Gather path(s). Nor could the hook safely
remove partial paths, for the same reason that they might already be
embedded in Gathers.
Better to call extensions first, let them add partial paths as desired,
and then gather. In v11 and up, we already doubled down on that ordering
by postponing gathering even further for single-relation queries; so even
if the hook wished to editorialize on Gather path construction, it could
not.
Report and patch by KaiGai Kohei. Back-patch to 9.6 where Gather paths
were added.
Discussion: https://postgr.es/m/CAOP8fzahwpKJRTVVTqo2AE=mDTz_efVzV6Get_0=U3SO+-ha1A@mail.gmail.com
M doc/src/sgml/custom-scan.sgml
M src/backend/optimizer/path/allpaths.c
For 11 only, put back heap_expand_tuple to GetTupleForTrigger().
commit : 920311ab18aac799aee6ad2303b2ed2b6b44c1b8
author : Andres Freund <[email protected]>
date : Sat, 9 Feb 2019 02:44:10 -0800
committer: Andres Freund <[email protected]>
date : Sat, 9 Feb 2019 02:44:10 -0800
This is not necessary anymore after 297d627e, but extensions that have
not been recompiled after the fix will not use the new definition of
heap_getattr(). While recompiling those extensions is obviously the
suggested course, it's cheap enough to retain the expansion in
GetTupleForTrigger().
Per suggestion from Andrew Gierth.
Discussion: [email protected]
M src/backend/commands/trigger.c
Reset, not recreate, execGrouping.c style hashtables.
commit : 35afccaba6d0e0aa14e3d1f859e6d84e69aee2cc
author : Andres Freund <[email protected]>
date : Sat, 9 Feb 2019 00:35:57 -0800
committer: Andres Freund <[email protected]>
date : Sat, 9 Feb 2019 00:35:57 -0800
This uses the facility added in the preceding commit to fix
performance issues caused by rebuilding the hashtable (with its
comparator expression being the most expensive bit), after every
reset. That's especially important when the comparator is JIT
compiled.
Bug: #15592 #15486
Reported-By: Jakub Janeček, Dmitry Marakasov
Author: Andres Freund
Discussion:
https://postgr.es/m/[email protected]
https://postgr.es/m/[email protected]
Backpatch: 11, where I broke this in bf6c614a2f2c5
M src/backend/executor/nodeAgg.c
M src/backend/executor/nodeRecursiveunion.c
M src/backend/executor/nodeSetOp.c
M src/backend/executor/nodeSubplan.c
Allow to reset execGrouping.c style tuple hashtables.
commit : 6455c65882474a48b6bde298bd04c18aa4e4b27f
author : Andres Freund <[email protected]>
date : Sat, 9 Feb 2019 00:35:57 -0800
committer: Andres Freund <[email protected]>
date : Sat, 9 Feb 2019 00:35:57 -0800
This has the advantage that the comparator expression, the table's
slot, etc do not have to be rebuilt. Additionally the simplehash.h
hashtable within the tuple hashtable now keeps its previous size and
doesn't need to be reallocated. That both reduces allocator overhead,
and improves performance in cases where the input estimation was off
by a significant factor.
To avoid an API/ABI break, the new parameter is exposed via the new
BuildTupleHashTableExt(), and BuildTupleHashTable() now is a wrapper
around the former, that continues to allocate the table itself in the
tablecxt.
Using this fixes performance issues discovered in the two bugs
referenced. This commit however has not converted the callers, that's
done in a separate commit.
Bug: #15592 #15486
Reported-By: Jakub Janeček, Dmitry Marakasov
Author: Andres Freund
Discussion:
https://postgr.es/m/[email protected]
https://postgr.es/m/[email protected]
Backpatch: 11, this is a prerequisite for other fixes
M src/backend/executor/execGrouping.c
M src/include/executor/executor.h
simplehash: Add support for resetting a hashtable's contents.
commit : 350b0a40375e5fa171da15bd3062de83c54cd099
author : Andres Freund <[email protected]>
date : Sat, 9 Feb 2019 00:35:57 -0800
committer: Andres Freund <[email protected]>
date : Sat, 9 Feb 2019 00:35:57 -0800
A hashtable reset just reset the hashtable entries, but does not free
memory.
Author: Andres Freund
Discussion: https://postgr.es/m/[email protected]
Bug: #15592 #15486
Backpatch: 11, this is a prerequisite for other fixes
M src/include/lib/simplehash.h
Plug leak in BuildTupleHashTable by creating ExprContext in correct context.
commit : 9cf37a527cf83e94f8f166d380baf53287a0337b
author : Andres Freund <[email protected]>
date : Sat, 9 Feb 2019 00:35:57 -0800
committer: Andres Freund <[email protected]>
date : Sat, 9 Feb 2019 00:35:57 -0800
In bf6c614a2f2c5 I added a expr context to evaluate the grouping
expression. Unfortunately the code I added initialized them while in
the calling context, rather the table context. Additionally, I used
CreateExprContext() rather than CreateStandaloneExprContext(), which
creates the econtext in the estate's query context.
Fix that by using CreateStandaloneExprContext when in the table's
tablecxt. As we rely on the memory being freed by a memory context
reset that means that the econtext's shutdown callbacks aren't being
called, but that seems ok as the expressions are tightly controlled
due to ExecBuildGroupingEqual().
Bug: #15592
Reported-By: Dmitry Marakasov
Author: Andres Freund
Discussion: https://postgr.es/m/[email protected]
Backpatch: 11, where I broke this in bf6c614a2f2c5
M src/backend/executor/execGrouping.c
First-draft release notes for 11.2.
commit : 5996cfc4665735a7e6e8d473bd66e8b11e320bbb
author : Tom Lane <[email protected]>
date : Fri, 8 Feb 2019 20:17:14 -0500
committer: Tom Lane <[email protected]>
date : Fri, 8 Feb 2019 20:17:14 -0500
As usual, the release notes for other branches will be made by cutting
these down, but put them up for community review first.
M doc/src/sgml/release-11.sgml
Defend against null error message reported by libxml2.
commit : 8e2956734b98933f833c7845da724c7a6d98341d
author : Tom Lane <[email protected]>
date : Fri, 8 Feb 2019 13:30:42 -0500
committer: Tom Lane <[email protected]>
date : Fri, 8 Feb 2019 13:30:42 -0500
While this isn't really supposed to happen, it can occur in OOM
situations and perhaps others. Instead of crashing, substitute
"(no message provided)".
I didn't worry about localizing this text, since we aren't
localizing anything else here; besides, if we're on the edge of
OOM, it's unlikely gettext() would work.
Report and fix by Sergio Conde Gómez in bug #15624.
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/adt/xml.c
Doc: fix thinko in description of how to escape a backslash in bytea.
commit : 8cf3fada2f87f2cbd0102389bf59434b45e911fe
author : Tom Lane <[email protected]>
date : Fri, 8 Feb 2019 12:49:36 -0500
committer: Tom Lane <[email protected]>
date : Fri, 8 Feb 2019 12:49:36 -0500
Also clean up some discussion that had been left in a very confused
state thanks to half-hearted adjustments for the change to
standard_conforming_strings being the default.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/datatype.sgml
Ensure that foreign scans with lateral refs are planned correctly.
commit : 9d6d2b21343db76a769fbcae72fbcbc18aa388cb
author : Tom Lane <[email protected]>
date : Thu, 7 Feb 2019 13:10:46 -0500
committer: Tom Lane <[email protected]>
date : Thu, 7 Feb 2019 13:10:46 -0500
As reported in bug #15613 from Srinivasan S A, file_fdw and postgres_fdw
neglected to mark plain baserel foreign paths as parameterized when the
relation has lateral_relids. Other FDWs have surely copied this mistake,
so rather than just patching those two modules, install a band-aid fix
in create_foreignscan_path to rectify the mistake centrally.
Although the band-aid is enough to fix the visible symptom, correct
the calls in file_fdw and postgres_fdw anyway, so that they are valid
examples for external FDWs.
Also, since the band-aid isn't enough to make this work for parameterized
foreign joins, throw an elog(ERROR) if such a case is passed to
create_foreignscan_path. This shouldn't pose much of a problem for
existing external FDWs, since it's likely they aren't trying to make such
paths anyway (though some of them may need a defense against joins with
lateral_relids, similar to the one this patch installs into postgres_fdw).
Add some assertions in relnode.c to catch future occurrences of the same
error --- in particular, as backstop against core-code mistakes like the
one fixed by commit bdd9a99aa.
Discussion: https://postgr.es/m/[email protected]
M contrib/file_fdw/file_fdw.c
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/postgres_fdw.c
M contrib/postgres_fdw/sql/postgres_fdw.sql
M src/backend/optimizer/util/pathnode.c
M src/backend/optimizer/util/relnode.c
Fix searchpath and module location for pg_rewind and ssl TAP tests
commit : 8722d2cbc0500b8ae1ebaf0a388115617615c1eb
author : Andrew Dunstan <[email protected]>
date : Thu, 7 Feb 2019 10:22:49 -0500
committer: Andrew Dunstan <[email protected]>
date : Thu, 7 Feb 2019 10:22:49 -0500
The modules RewindTest.pm and ServerSetup.pm are really only useful for
TAP tests, so they really belong in the TAP test directories. In
addition, ServerSetup.pm is renamed to SSLServer.pm.
The test scripts have their own directories added to the search path so
that the relocated modules will be found, regardless of where the tests
are run from, even on modern perl where "." is no longer in the
searchpath.
Discussion: https://postgr.es/m/[email protected]
Backpatch as appropriate to 9.5
M src/bin/pg_rewind/t/001_basic.pl
M src/bin/pg_rewind/t/002_databases.pl
M src/bin/pg_rewind/t/003_extrafiles.pl
M src/bin/pg_rewind/t/004_pg_xlog_symlink.pl
M src/bin/pg_rewind/t/005_same_timeline.pl
R100 src/bin/pg_rewind/RewindTest.pm src/bin/pg_rewind/t/RewindTest.pm
M src/test/ssl/t/001_ssltests.pl
M src/test/ssl/t/002_scram.pl
R099 src/test/ssl/ServerSetup.pm src/test/ssl/t/SSLServer.pm
Add collation assignment to CALL statement
commit : 004f494b513c3398030983b2644eeea8776c0a5d
author : Peter Eisentraut <[email protected]>
date : Tue, 5 Feb 2019 15:08:53 +0100
committer: Peter Eisentraut <[email protected]>
date : Tue, 5 Feb 2019 15:08:53 +0100
Otherwise functions that require collation information will not have
it if they are called in arguments to a CALL statement.
Reported-by: Jean-Marc Voillequin <[email protected]>
Reviewed-by: Tom Lane <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/1EC8157EB499BF459A516ADCF135ADCE39FFAC54%40LON-WGMSX712.ad.moodys.net
M src/backend/parser/analyze.c
M src/test/regress/expected/create_procedure.out
M src/test/regress/sql/create_procedure.sql
Doc: Update the documentation for row movement behavior across partitions.
commit : d850af428deb21d074330f6fe801c52e52965fde
author : Amit Kapila <[email protected]>
date : Thu, 7 Feb 2019 09:02:45 +0530
committer: Amit Kapila <[email protected]>
date : Thu, 7 Feb 2019 09:02:45 +0530
In commit f16241bef7c, we have changed the behavior for concurrent updates
that move row to a different partition, but forgot to update the docs.
Previously when an UPDATE command causes a row to move from one partition
to another, there is a chance that another concurrent UPDATE or DELETE
misses this row. However, now we raise a serialization failure error in
such a case.
Reported-by: David Rowley
Author: David Rowley and Amit Kapila
Backpatch-through: 11 where it was introduced
Discussion: https://postgr.es/m/CAKJS1f-iVhGD4-givQWpSROaYvO3c730W8yoRMTF9Gc3craY3w@mail.gmail.com
M doc/src/sgml/ddl.sgml
Avoid amcheck inline compression false positives.
commit : 2f541666683be0608594fad79acbe5619b49734c
author : Peter Geoghegan <[email protected]>
date : Wed, 6 Feb 2019 15:54:17 -0800
committer: Peter Geoghegan <[email protected]>
date : Wed, 6 Feb 2019 15:54:17 -0800
The previous tacit assumption that index_form_tuple() hides differences
in the TOAST state of its input datums was wrong. Normalize input
varlena datums by decompressing compressed values, and forming a new
index tuple for fingerprinting using uncompressed inputs. The final
normalized representation may actually be compressed once again within
index_form_tuple(), though that shouldn't matter. When the original
tuple is found to have no datums that are compressed inline, fingerprint
the original tuple directly.
Normalization avoids false positive reports of corruption in certain
cases. For example, the executor can apply toasting with some inline
compression to an entire heap tuple because its input has a single
external TOAST pointer. Varlena datums for other attributes that are
not particularly good candidates for inline compression can be
compressed in the heap tuple in passing, without the representation of
the same values in index tuples ever receiving concomitant inline
compression.
Add a test case to recreate the issue in a simpler though less realistic
way: by exploiting differences in pg_attribute.attstorage between heap
and index relations.
This bug was discovered by me during testing of an upcoming set of nbtree
enhancements. It was also independently reported by Andreas Kunert, as
bug #15597. His test case was rather more realistic than the one I
ended up using.
Bug: #15597
Discussion: https://postgr.es/m/CAH2-WznrVd9ie+TTJ45nDT+v2nUt6YJwQrT9SebCdQKtAvfPZw@mail.gmail.com
Discussion: https://postgr.es/m/[email protected]
Backpatch: 11-, where heapallindexed verification was introduced.
M contrib/amcheck/expected/check_btree.out
M contrib/amcheck/sql/check_btree.sql
M contrib/amcheck/verify_nbtree.c
Propagate lateral-reference information to indirect descendant relations.
commit : 45ae2031ec1514ea403a85961f155296bc4be350
author : Tom Lane <[email protected]>
date : Wed, 6 Feb 2019 12:44:58 -0500
committer: Tom Lane <[email protected]>
date : Wed, 6 Feb 2019 12:44:58 -0500
create_lateral_join_info() computes a bunch of information about lateral
references between base relations, and then attempts to propagate those
markings to appendrel children of the original base relations. But the
original coding neglected the possibility of indirect descendants
(grandchildren etc). During v11 development we noticed that this was
wrong for partitioned-table cases, but failed to realize that it was just
as wrong for any appendrel. While the case can't arise for appendrels
derived from traditional table inheritance (because we make a flat
appendrel for that), nested appendrels can arise from nested UNION ALL
subqueries. Failure to mark the lower-level relations as having lateral
references leads to confusion in add_paths_to_append_rel about whether
unparameterized paths can be built. It's not very clear whether that
leads to any user-visible misbehavior; the lack of field reports suggests
that it may cause nothing worse than minor cost misestimation. Still,
it's a bug, and it leads to failures of Asserts that I intend to add
later.
To fix, we need to propagate information from all appendrel parents,
not just those that are RELOPT_BASERELs. We can still do it in one
pass, if we rely on the append_rel_list to be ordered with ancestor
relationships before descendant ones; add assertions checking that.
While fixing this, we can make a small performance improvement by
traversing the append_rel_list just once instead of separately for
each appendrel parent relation.
Noted while investigating bug #15613, though this patch does not fix
that (which is why I'm not committing the related Asserts yet).
Discussion: https://postgr.es/m/[email protected]
M src/backend/optimizer/plan/initsplan.c
Unify searchpath and do file logic in MSVC build scripts.
commit : 11f11e1e0103e56649e86dbaaf800a1b4a6d5ebe
author : Andrew Dunstan <[email protected]>
date : Wed, 6 Feb 2019 07:32:35 -0500
committer: Andrew Dunstan <[email protected]>
date : Wed, 6 Feb 2019 07:32:35 -0500
Commit f83419b739 failed to notice that mkvcbuild.pl and build.pl use
different searchpath and do-file logic, breaking the latter, so it is
adjusted to use the same logic as mkvcbuild.pl.
M src/tools/msvc/build.pl
Fix heap_getattr() handling of fast defaults.
commit : 297d627e074ad4aa2a9936b029a4b9231f9a150e
author : Andres Freund <[email protected]>
date : Wed, 6 Feb 2019 01:09:32 -0800
committer: Andres Freund <[email protected]>
date : Wed, 6 Feb 2019 01:09:32 -0800
Previously heap_getattr() returned NULL for attributes with a fast
default value (c.f. 16828d5c0273), as it had no handling whatsoever
for that case.
A previous fix, 7636e5c60f, attempted to fix issues caused by this
oversight, but just expanding OLD tuples for triggers doesn't actually
solve the underlying issue.
One known consequence of this bug is that the check for HOT updates
can return the wrong result, when a previously fast-default'ed column
is set to NULL. Which in turn means that an index over a column with
fast default'ed columns might be corrupt if the underlying column(s)
allow NULLs.
Fix by handling fast default columns in heap_getattr(), remove now
superfluous expansion in GetTupleForTrigger().
Author: Andres Freund
Discussion: https://postgr.es/m/[email protected]
Backpatch: 11, where fast defaults were introduced
M src/backend/access/common/heaptuple.c
M src/backend/commands/trigger.c
M src/include/access/htup_details.h
M src/test/regress/expected/fast_default.out
M src/test/regress/sql/fast_default.sql
Fix included file path for modern perl
commit : 77173d0cca4df1df1f423a467e2af4a4db9a0d10
author : Andrew Dunstan <[email protected]>
date : Tue, 5 Feb 2019 18:57:12 -0500
committer: Andrew Dunstan <[email protected]>
date : Tue, 5 Feb 2019 18:57:12 -0500
Contrary to the comment on 772d4b76, only paths starting with "./" or
"../" are considered relative to the current working directory by perl's
"do" function. So this patch converts all the relevant cases to use "./"
paths. This only affects MSVC.
Backpatch to all live branches.
M src/tools/msvc/Install.pm
M src/tools/msvc/build.pl
M src/tools/msvc/install.pl
M src/tools/msvc/mkvcbuild.pl
M src/tools/msvc/pgbison.pl
M src/tools/msvc/pgflex.pl
M src/tools/msvc/vcregress.pl
Keep perl style checker happy
commit : 99eb3bba649b5a48fa9b679b6d94334ca110e1db
author : Andrew Dunstan <[email protected]>
date : Tue, 5 Feb 2019 15:16:55 -0500
committer: Andrew Dunstan <[email protected]>
date : Tue, 5 Feb 2019 15:16:55 -0500
It doesn't like code before "use strict;".
M src/backend/catalog/genbki.pl
Update time zone data files to tzdata release 2018i.
commit : 46b454096973fee0fb55c092496fdf8005eea885
author : Tom Lane <[email protected]>
date : Tue, 5 Feb 2019 10:58:53 -0500
committer: Tom Lane <[email protected]>
date : Tue, 5 Feb 2019 10:58:53 -0500
DST law changes in Kazakhstan, Metlakatla, and São Tomé and Príncipe.
Kazakhstan's Qyzylorda zone is split in two, creating a new zone
Asia/Qostanay, as some areas did not change UTC offset.
Historical corrections for Hong Kong and numerous Pacific islands.
M src/timezone/data/tzdata.zi
Fix searchpath for modern Perl for genbki.pl
commit : 4e7a5130271fcc579f89d3f7ae6b69e73d37c32a
author : Andrew Dunstan <[email protected]>
date : Tue, 5 Feb 2019 09:59:46 -0500
committer: Andrew Dunstan <[email protected]>
date : Tue, 5 Feb 2019 09:59:46 -0500
This was fixed for MSVC tools by commit 1df92eeafefac4, but per
buildfarm member bowerbird genbki.pl needs the same treatment.
Backpatch to all live branches.
M src/backend/catalog/genbki.pl
Doc: in each release branch, keep only that branch's own release notes.
commit : 0d13dd371b64c52221ba220d214d8fbce3e474f5
author : Tom Lane <[email protected]>
date : Mon, 4 Feb 2019 19:18:50 -0500
committer: Tom Lane <[email protected]>
date : Mon, 4 Feb 2019 19:18:50 -0500
Historically we've had each release branch include all prior branches'
notes, including minor-release changes, back to the beginning of the
project. That's basically an O(N^2) proposition, and it was starting to
catch up with us: as of HEAD the back-branch release notes alone accounted
for nearly 30% of the documentation. While there's certainly some value
in easy access to back-branch notes, this is getting out of hand.
Hence, switch over to the rule that each branch contains only its own
release notes. So as to not make older notes too hard to find, each
branch will provide URLs for the immediately preceding branches'
release notes on the project website.
There might be value in providing aggregated notes across all branches
somewhere on the website, but that's a task for another day.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/filelist.sgml
D doc/src/sgml/release-10.sgml
D doc/src/sgml/release-7.4.sgml
D doc/src/sgml/release-8.0.sgml
D doc/src/sgml/release-8.1.sgml
D doc/src/sgml/release-8.2.sgml
D doc/src/sgml/release-8.3.sgml
D doc/src/sgml/release-8.4.sgml
D doc/src/sgml/release-9.0.sgml
D doc/src/sgml/release-9.1.sgml
D doc/src/sgml/release-9.2.sgml
D doc/src/sgml/release-9.3.sgml
D doc/src/sgml/release-9.4.sgml
D doc/src/sgml/release-9.5.sgml
D doc/src/sgml/release-9.6.sgml
D doc/src/sgml/release-old.sgml
M doc/src/sgml/release.sgml
Fix dumping of matviews with indirect dependencies on primary keys.
commit : b8de846a511a8328faaac792641253054cc6c6e9
author : Tom Lane <[email protected]>
date : Mon, 4 Feb 2019 17:20:02 -0500
committer: Tom Lane <[email protected]>
date : Mon, 4 Feb 2019 17:20:02 -0500
Commit 62215de29 turns out to have been not quite on-the-mark.
When we are forced to postpone dumping of a materialized view into
the dump's post-data section (because it depends on a unique index
that isn't created till that section), we may also have to postpone
dumping other matviews that depend on said matview. The previous fix
didn't reliably work for such cases: it'd break the dependency loops
properly, producing a workable object ordering, but it didn't
necessarily mark all the matviews as "postponed_def". This led to
harmless bleating about "archive items not in correct section order",
as reported by Tom Cassidy in bug #15602. Less harmlessly,
selective-restore options such as --section might misbehave due to
the matview dump objects not being properly labeled.
The right way to fix it is to consider that each pre-data dependency
we break amounts to moving the no-longer-dependent object into
post-data, and hence we should mark that object if it's a matview.
Back-patch to all supported versions, since the issue's been there
since matviews were introduced.
Discussion: https://postgr.es/m/[email protected]
M src/bin/pg_dump/pg_dump_sort.c
Move port-specific parts of with_temp_install to port makefile.
commit : ed1bb25075c5f12993af66bb0aba114f843b2764
author : Andrew Gierth <[email protected]>
date : Mon, 4 Feb 2019 18:47:33 +0000
committer: Andrew Gierth <[email protected]>
date : Mon, 4 Feb 2019 18:47:33 +0000
Rather than define ld_library_path_ver with a big nested $(if), just
put the overriding values in the makefiles for the relevant ports.
Also add a variable for port makefiles to append their own stuff to
with_temp_install, and use it to set LD_LIBRARY_PATH_RPATH=1 on
FreeBSD which is needed to make LD_LIBRARY_PATH override DT_RPATH
if DT_RUNPATH is not set (which seems to depend in unpredictable ways
on the choice of compiler, at least on my system).
Backpatch for the benefit of anyone doing regression tests on FreeBSD.
(For other platforms there should be no functional change.)
M src/Makefile.global.in
M src/makefiles/Makefile.aix
M src/makefiles/Makefile.darwin
M src/makefiles/Makefile.freebsd
M src/makefiles/Makefile.hpux
Clarify behavior of initdb's --allow-group-access on Windows in docs
commit : 40e821b01870a1de5e3fdcf5c76d46116c0a56b7
author : Michael Paquier <[email protected]>
date : Mon, 4 Feb 2019 09:57:36 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 4 Feb 2019 09:57:36 +0900
The option is ignored on Windows, and GUC data_directory_mode already
mentioned that within its description in the documentation.
Author: Michael Paquier
Reported-by: Haribabu Kommi, David Steele
Discussion: https://postgr.es/m/CAJrrPGefxTG43yk6BrOC7ZcMnCTccG9+inCSncvyys_t8Ev9cQ@mail.gmail.com
Backpatch-through: 11
M doc/src/sgml/ref/initdb.sgml
Add PG_CFLAGS, PG_CXXFLAGS, and PG_LDFLAGS variables to PGXS
commit : 946430da6a0b91cac5607758264f506d25b3321f
author : Michael Paquier <[email protected]>
date : Sun, 3 Feb 2019 17:48:35 +0900
committer: Michael Paquier <[email protected]>
date : Sun, 3 Feb 2019 17:48:35 +0900
Add PG_CFLAGS, PG_CXXFLAGS, and PG_LDFLAGS variables to pgxs.mk which
will be appended or prepended to the corresponding make variables.
Notably, there was previously no way to pass custom CXXFLAGS to third
party extension module builds, COPT and PROFILE supporting only CFLAGS
and LDFLAGS.
Backpatch all the way down to ease integration with existing
extensions.
Author: Christoph Berg
Reviewed-by: Andres Freund, Tom Lane, Michael Paquier
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4
M doc/src/sgml/extend.sgml
M src/makefiles/pgxs.mk
Avoid possible deadlock while locking multiple heap pages.
commit : 904413637f8b04aab02cbe03173a1a0bdadc2b6b
author : Amit Kapila <[email protected]>
date : Sat, 2 Feb 2019 08:38:26 +0530
committer: Amit Kapila <[email protected]>
date : Sat, 2 Feb 2019 08:38:26 +0530
To avoid deadlock, backend acquires a lock on heap pages in block
number order. In certain cases, lock on heap pages is dropped and
reacquired. In this case, the locks are dropped for reading in
corresponding VM page/s. The issue is we re-acquire locks in bufferId
order whereas the intention was to acquire in blockid order.
This commit ensures that we will always acquire locks on heap pages in
blockid order.
Reported-by: Nishant Fnu
Author: Nishant Fnu
Reviewed-by: Amit Kapila and Robert Haas
Backpatch-through: 9.4
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/heap/hio.c
Fix use of dangling pointer in heap_delete() when logging replica identity
commit : 47412e075266a5f23c66aaaf3abbb76b075c2c15
author : Michael Paquier <[email protected]>
date : Fri, 1 Feb 2019 10:35:40 +0900
committer: Michael Paquier <[email protected]>
date : Fri, 1 Feb 2019 10:35:40 +0900
When logging the replica identity of a deleted tuple, XLOG_HEAP_DELETE
records include references of the old tuple. Its data is stored in an
intermediate variable used to register this information for the WAL
record, but this variable gets away from the stack when the record gets
actually inserted.
Spotted by clang's AddressSanitizer.
Author: Stas Kelvish
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4
M src/backend/access/heap/heapam.c
Fix a crash in logical replication
commit : cf25498f718a35addf0fc783691538d91d60dcf8
author : Peter Eisentraut <[email protected]>
date : Mon, 28 Jan 2019 22:09:33 +0100
committer: Peter Eisentraut <[email protected]>
date : Mon, 28 Jan 2019 22:09:33 +0100
The bug was that determining which columns are part of the replica
identity index using RelationGetIndexAttrBitmap() would run
eval_const_expressions() on index expressions and predicates across
all indexes of the table, which in turn might require a snapshot, but
there wasn't one set, so it crashes. There were actually two separate
bugs, one on the publisher and one on the subscriber.
To trigger the bug, a table that is part of a publication or
subscription needs to have an index with a predicate or expression
that lends itself to constant expressions simplification.
The fix is to avoid the constant expressions simplification in
RelationGetIndexAttrBitmap(), so that it becomes safe to call in these
contexts. The constant expressions simplification comes from the
calls to RelationGetIndexExpressions()/RelationGetIndexPredicate() via
BuildIndexInfo(). But RelationGetIndexAttrBitmap() calling
BuildIndexInfo() is overkill. The latter just takes pg_index catalog
information, packs it into the IndexInfo structure, which former then
just unpacks again and throws away. We can just do this directly with
less overhead and skip the troublesome calls to
eval_const_expressions(). This also removes the awkward
cross-dependency between relcache.c and index.c.
Bug: #15114
Reported-by: Петър Славов <[email protected]>
Reviewed-by: Noah Misch <[email protected]>
Reviewed-by: Michael Paquier <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/[email protected]/
M src/backend/utils/cache/relcache.c
A src/test/subscription/t/100_bugs.pl
Improve wording about WAL files in tar mode of pg_basebackup
commit : ff9e63c7d33a92503895b3c8acc8d96cb8116220
author : Magnus Hagander <[email protected]>
date : Tue, 29 Jan 2019 10:42:41 +0100
committer: Magnus Hagander <[email protected]>
date : Tue, 29 Jan 2019 10:42:41 +0100
Author: Alex Kliukin
Reviewed-By: Michael Paquier, Magnus Hagander
M doc/src/sgml/ref/pg_basebackup.sgml
Fix LLVM related headers to compile standalone (to fix cpluspluscheck).
commit : 6a5c0bb6abbfa987ac065789b50240e485b75725
author : Andres Freund <[email protected]>
date : Mon, 28 Jan 2019 18:05:52 -0800
committer: Andres Freund <[email protected]>
date : Mon, 28 Jan 2019 18:05:52 -0800
Previously llvmjit.h #error'ed when USE_LLVM was not defined, to
prevent it from being included from code not having #ifdef USE_LLVM
guards - but that's not actually that useful after, during the
development of JIT support, LLVM related code was moved into a
separately compiled .so. Having that #error means cpluspluscheck
doesn't work when llvm support isn't enabled, which isn't great.
Similarly add USE_LLVM guards to llvmjit_emit.h, and additionally make
sure it compiles standalone.
Per complaint from Tom Lane.
Author: Andres Freund
Discussion: https://postgr.es/m/[email protected]
Backpatch: 11, where JIT support was added
M src/include/jit/llvmjit.h
M src/include/jit/llvmjit_emit.h
Install JIT related headers.
commit : 453be7d4dd03a4589bca753dabcff786c277de4f
author : Andres Freund <[email protected]>
date : Mon, 28 Jan 2019 13:51:12 -0800
committer: Andres Freund <[email protected]>
date : Mon, 28 Jan 2019 13:51:12 -0800
There's no reason not to install these, and jit.h can be useful for
users of e.g. planner hooks.
Author: Donald Dong
Reviewed-By: Andres Freund
Discussion: https://postgr.es/m/[email protected]
Backpatch: 11-, where JIT compilation was introduced
M src/include/Makefile
Allow for yet another crash symptom in 013_crash_restart.pl.
commit : 04bbefcc30f0f41066607da319dea58e3a319433
author : Tom Lane <[email protected]>
date : Sat, 26 Jan 2019 22:12:49 -0500
committer: Tom Lane <[email protected]>
date : Sat, 26 Jan 2019 22:12:49 -0500
Given the right timing, psql could emit "connection to server was lost"
rather than one of the other messages that this test script checked for.
It looks like commit 4247db625 may have made this more likely, but
I don't really believe it was impossible before then. Rather than
stress about it, just add that spelling as one of the crash-successfully-
detected cases.
Discussion: https://postgr.es/m/[email protected]
M src/test/recovery/t/013_crash_restart.pl
Fix psql's "\g target" meta-command to work with COPY TO STDOUT.
commit : 2c50c9f23d1dbb36b4fed50409ec590a0e9adaa2
author : Tom Lane <[email protected]>
date : Sat, 26 Jan 2019 14:15:42 -0500
committer: Tom Lane <[email protected]>
date : Sat, 26 Jan 2019 14:15:42 -0500
Previously, \g would successfully execute the COPY command, but
the target specification if any was ignored, so that the data was
always dumped to the regular query output target. This seems like
a clear bug, so let's not just fix it but back-patch it.
While at it, adjust the documentation for \copy to recommend
"COPY ... TO STDOUT \g foo" as a plausible alternative.
Back-patch to 9.5. The problem exists much further back, but the
code associated with \g was refactored enough in 9.5 that we'd
need a significantly different patch for 9.4, and it doesn't
seem worth the trouble.
Daniel Vérité, reviewed by Fabien Coelho
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ref/psql-ref.sgml
M src/bin/psql/common.c
M src/bin/psql/copy.c
Allow UNLISTEN in hot-standby mode.
commit : c0aed6959541f1ce3930977c8cf8dd874308a1b5
author : Tom Lane <[email protected]>
date : Fri, 25 Jan 2019 21:14:31 -0500
committer: Tom Lane <[email protected]>
date : Fri, 25 Jan 2019 21:14:31 -0500
Since LISTEN is (still) disallowed, UNLISTEN must be a no-op in a
hot-standby session, and so there's no harm in allowing it. This
change allows client code to not worry about whether it's connected
to a primary or standby server when performing session-state-reset
type activities. (Note that DISCARD ALL, which includes UNLISTEN,
was already allowed, making it inconsistent to reject UNLISTEN.)
Per discussion, back-patch to all supported versions.
Shay Rojansky, reviewed by Mi Tar
Discussion: https://postgr.es/m/CADT4RqCf2gA_TJtPAjnGzkC3ZiexfBZiLmA-mV66e4UyuVv8bA@mail.gmail.com
M doc/src/sgml/high-availability.sgml
M src/backend/tcop/utility.c
M src/test/regress/expected/hs_standby_allowed.out
M src/test/regress/expected/hs_standby_disallowed.out
M src/test/regress/sql/hs_standby_allowed.sql
M src/test/regress/sql/hs_standby_disallowed.sql
Remove infinite-loop hazards in ecpg test suite.
commit : 28868f77b6cb531fca376767c29c9767ac39f54b
author : Tom Lane <[email protected]>
date : Thu, 24 Jan 2019 16:46:55 -0500
committer: Tom Lane <[email protected]>
date : Thu, 24 Jan 2019 16:46:55 -0500
A report from Andrew Dunstan showed that an ecpglib breakage that
causes repeated query failures could lead to infinite loops in some
ecpg test scripts, because they contain "while(1)" loops with no
exit condition other than successful test completion. That might
be all right for manual testing, but it seems entirely unacceptable
for automated test environments such as our buildfarm. We don't
want buildfarm owners to have to intervene manually when a test
goes wrong.
To fix, just change all those while(1) loops to exit after at most
100 iterations (which is more than any of them expect to iterate).
This seems sufficient since we'd see discrepancies in the test output
if any loop executed the wrong number of times.
I tested this by dint of intentionally breaking ecpg_do_prologue
to always fail, and verifying that the tests still got to completion.
Back-patch to all supported branches, since the whole point of this
exercise is to protect the buildfarm against future mistakes.
Discussion: https://postgr.es/m/[email protected]
M src/interfaces/ecpg/test/compat_informix/test_informix.pgc
M src/interfaces/ecpg/test/compat_oracle/char_array.pgc
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-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-fetch.c
M src/interfaces/ecpg/test/expected/sql-quote.c
M src/interfaces/ecpg/test/pgtypeslib/nan_test.pgc
M src/interfaces/ecpg/test/preproc/autoprep.pgc
M src/interfaces/ecpg/test/preproc/outofscope.pgc
M src/interfaces/ecpg/test/preproc/variable.pgc
M src/interfaces/ecpg/test/preproc/whenever_do_continue.pgc
M src/interfaces/ecpg/test/sql/fetch.pgc
M src/interfaces/ecpg/test/sql/quote.pgc
Fix droppability of constraints upon partition detach
commit : 1ad5210998e33cccb4ea97b33837f19193d1011d
author : Alvaro Herrera <[email protected]>
date : Thu, 24 Jan 2019 14:09:56 -0300
committer: Alvaro Herrera <[email protected]>
date : Thu, 24 Jan 2019 14:09:56 -0300
We were failing to set conislocal correctly for constraints in
partitions after partition detach, leading to those constraints becoming
undroppable. Fix by setting the flag correctly. Existing databases
might contain constraints with the conislocal wrongly set to false, for
partitions that were detached; this situation should be fixable by
applying an UPDATE on pg_constraint to set conislocal true. This
problem should otherwise be innocuous and should disappear across a
dump/restore or pg_upgrade.
Secondarily, when constraint drop was attempted in a partitioned table,
ATExecDropConstraint would try to recurse to partitions after doing
performDeletion() of the constraint in the partitioned table itself; but
since the constraint in the partitions are dropped by the initial call
of performDeletion() (because of following dependencies), the recursion
step would fail since it would not find the constraint, causing the
whole operation to fail. Fix by preventing recursion.
Reported-by: Amit Langote
Diagnosed-by: Amit Langote
Author: Amit Langote, Álvaro Herrera
Discussion: https://postgr.es/m/[email protected]
M src/backend/catalog/pg_constraint.c
M src/backend/commands/tablecmds.c
M src/test/regress/expected/foreign_key.out
M src/test/regress/sql/foreign_key.sql
Fix portability problem in pgbench.
commit : 27d6bc68f98e062a4af625fd5044ba7e23a2003f
author : Tom Lane <[email protected]>
date : Thu, 24 Jan 2019 11:31:54 -0500
committer: Tom Lane <[email protected]>
date : Thu, 24 Jan 2019 11:31:54 -0500
The pgbench regression test supposed that srandom() with a specific value
would result in deterministic output from random(), as required by POSIX.
It emerges however that OpenBSD is too smart to be constrained by mere
standards, so their random() emits nondeterministic output anyway.
While a workaround does exist, what seems like a better fix is to stop
relying on the platform's srandom()/random() altogether, so that what
you get from --random-seed=N is not merely deterministic but platform
independent. Hence, use a separate pg_jrand48() random sequence in
place of random().
Also adjust the regression test case that's supposed to detect
nondeterminism so that it's more likely to detect it; the original
choice of random_zipfian parameter tended to produce the same output
all the time even if the underlying behavior wasn't deterministic.
In passing, improve pgbench's docs about random_zipfian().
Back-patch to v11 where this code was introduced.
Fabien Coelho and Tom Lane
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ref/pgbench.sgml
M src/bin/pgbench/pgbench.c
M src/bin/pgbench/t/001_pgbench_with_server.pl
Simplify coding to detach constraints when detaching partition
commit : 71eba83999f3702ee9b909ad2df5cae7ebb58882
author : Alvaro Herrera <[email protected]>
date : Thu, 24 Jan 2019 11:18:35 -0300
committer: Alvaro Herrera <[email protected]>
date : Thu, 24 Jan 2019 11:18:35 -0300
The original coding was too baroque and led to an use-after-release
mistake, noticed by buildfarm member prion.
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/tablecmds.c
Blind attempt to fix _configthreadlocale() failures on MinGW.
commit : b620cf2d47625280e631127ae7202e798257647d
author : Tom Lane <[email protected]>
date : Wed, 23 Jan 2019 22:46:45 -0500
committer: Tom Lane <[email protected]>
date : Wed, 23 Jan 2019 22:46:45 -0500
Apparently, some builds of MinGW contain a version of
_configthreadlocale() that always returns -1, indicating failure.
Rather than treating that as a curl-up-and-die condition, soldier on
as though the function didn't exist. This leaves us without thread
safety on such MinGW versions, but we didn't have it anyway.
Discussion: https://postgr.es/m/[email protected]
M src/interfaces/ecpg/ecpglib/descriptor.c
M src/interfaces/ecpg/ecpglib/execute.c
Detach constraints when partitions are detached
commit : 00376eaa2ec28db92efe349a895164b0e31b314c
author : Alvaro Herrera <[email protected]>
date : Wed, 23 Jan 2019 23:57:46 -0300
committer: Alvaro Herrera <[email protected]>
date : Wed, 23 Jan 2019 23:57:46 -0300
I (Álvaro) forgot to do this in eb7ed3f30634, leading to undroppable
constraints after partitions are detached. Repair.
Reported-by: Amit Langote
Author: Amit Langote
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/tablecmds.c
M src/test/regress/expected/indexing.out
M src/test/regress/sql/indexing.sql
Fix misc typos in comments.
commit : 0359d832128485840bd7dcf0b09646ad752f6a72
author : Heikki Linnakangas <[email protected]>
date : Wed, 23 Jan 2019 13:39:00 +0200
committer: Heikki Linnakangas <[email protected]>
date : Wed, 23 Jan 2019 13:39:00 +0200
Spotted mostly by Fabien Coelho.
Discussion: https://www.postgresql.org/message-id/alpine.DEB.2.21.1901230947050.16643@lancre
M contrib/pgcrypto/pgp-decrypt.c
M src/backend/access/gin/ginget.c
M src/backend/executor/execParallel.c
M src/backend/parser/gram.y
M src/backend/utils/cache/typcache.c
M src/bin/pgbench/pgbench.c
M src/include/nodes/execnodes.h
M src/include/port.h
M src/pl/plpython/plpy_elog.c
Doc: fix typo in URL of OASIS group web site.
commit : 77002ad375a8ca6b7587560208303cf2555d62bb
author : Tatsuo Ishii <[email protected]>
date : Wed, 23 Jan 2019 13:14:52 +0900
committer: Tatsuo Ishii <[email protected]>
date : Wed, 23 Jan 2019 13:14:52 +0900
In other places that has been changed from http://www.oasis-open.org/
https://www.oasis-open.org/ but there's a place where the change was
missed.
Discussion: https://postgr.es/m/20190121.222844.399814306477973879.t-ishii%40sraoss.co.jp
M doc/src/sgml/docguide.sgml
llvm: Fix file-ending in IDENTIFICATION comments.
commit : f6192660ab861a9308bc5d1d4613b71f896aeac6
author : Andres Freund <[email protected]>
date : Tue, 22 Jan 2019 11:46:59 -0800
committer: Andres Freund <[email protected]>
date : Tue, 22 Jan 2019 11:46:59 -0800
Author: Amit Langote
Discussion: https://postgr.es/m/[email protected]
Backpatch: 11-, where llvm was introduced.
M src/backend/jit/llvm/llvmjit_error.cpp
M src/backend/jit/llvm/llvmjit_inline.cpp
M src/backend/jit/llvm/llvmjit_wrap.cpp
Avoid thread-safety problem in ecpglib.
commit : f305e8457d1e19eb4e6f4e16f42061ebaf7cb509
author : Tom Lane <[email protected]>
date : Mon, 21 Jan 2019 23:18:58 -0500
committer: Tom Lane <[email protected]>
date : Mon, 21 Jan 2019 23:18:58 -0500
ecpglib attempts to force the LC_NUMERIC locale to "C" while reading
server output, to avoid problems with strtod() and related functions.
Historically it's just issued setlocale() calls to do that, but that
has major problems if we're in a threaded application. setlocale()
itself is not required by POSIX to be thread-safe (and indeed is not,
on recent OpenBSD). Moreover, its effects are process-wide, so that
we could cause unexpected results in other threads, or another thread
could change our setting.
On platforms having uselocale(), which is required by POSIX:2008,
we can avoid these problems by using uselocale() instead. Windows
goes its own way as usual, but we can make it safe by using
_configthreadlocale(). Platforms having neither continue to use the
old code, but that should be pretty much nobody among current systems.
(Subsequent buildfarm results show that recent NetBSD versions still
lack uselocale(), but it's not a big problem because they also do not
support non-"C" settings for LC_NUMERIC.)
Back-patch of commits 8eb4a9312 and ee27584c4.
Michael Meskes and Tom Lane; thanks also to Takayuki Tsunakawa.
Discussion: https://postgr.es/m/[email protected]
M configure
M configure.in
M src/include/pg_config.h.in
M src/include/pg_config.h.win32
M src/interfaces/ecpg/ecpglib/descriptor.c
M src/interfaces/ecpg/ecpglib/execute.c
M src/interfaces/ecpg/ecpglib/extern.h
Remove useless bms_copy step in RelationGetIndexAttrBitmap.
commit : 7fbdefd30e7c644bd7c6ec0799abb49584e01477
author : Tom Lane <[email protected]>
date : Mon, 21 Jan 2019 18:33:32 -0500
committer: Tom Lane <[email protected]>
date : Mon, 21 Jan 2019 18:33:32 -0500
Seems to be from a bad case of copy-and-paste-itis in commit 665d1fad9.
It wouldn't be quite so annoying if it didn't contradict the comment
half a dozen lines above.
David Rowley
Discussion: https://postgr.es/m/CAKJS1f95Dyf8Qkdz4W+PbCmT-HTb54tkqUCC8isa2RVgSJ_pXQ@mail.gmail.com
M src/backend/utils/cache/relcache.c
Create action triggers when partitions are detached
commit : 123cc697a8eb0827e82ceea3f6da55b2f05eb422
author : Alvaro Herrera <[email protected]>
date : Mon, 21 Jan 2019 19:59:07 -0300
committer: Alvaro Herrera <[email protected]>
date : Mon, 21 Jan 2019 19:59:07 -0300
Detaching a partition from a partitioned table that's constrained by
foreign keys requires additional action triggers on the referenced side;
otherwise, DELETE/UPDATE actions there fail to notice rows in the table
that was partition, and so are incorrectly allowed through. With this
commit, those triggers are now created. Conversely, when a table that
has a foreign key is attached as a partition to a table that also has
the same foreign key, those action triggers are no longer needed, so we
remove them.
Add a minimal test case verifying (part of) this.
Authors: Amit Langote, Álvaro Herrera
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/tablecmds.c
M src/test/regress/expected/foreign_key.out
M src/test/regress/sql/foreign_key.sql
Flush relcache entries when their FKs are meddled with
commit : a7474308ceafb6d73730507165f45ffdbd5429c8
author : Alvaro Herrera <[email protected]>
date : Mon, 21 Jan 2019 19:34:11 -0300
committer: Alvaro Herrera <[email protected]>
date : Mon, 21 Jan 2019 19:34:11 -0300
Back in commit 100340e2dcd0, we made relcache entries keep lists of the
foreign keys applying to the relation -- but we forgot to update
CacheInvalidateHeapTuple to flush those entries when new FKs got created
or existing ones updated/deleted. No bugs appear to have been reported
that would be explained by this ommission, but I noticed the problem
while working on an unrelated bugfix which clearly showed it. Fix by
adding relcache flush on relevant foreign key changes.
Backpatch to 9.6, like the aforementioned commit.
Discussion: https://postgr.es/m/[email protected]
Reviewed-by: Tom Lane
M src/backend/utils/cache/inval.c
Add 'id' to Acknowledgments section
commit : aa47fa8532effa95cb9ca6dbd2baba8a620bf67e
author : Alvaro Herrera <[email protected]>
date : Mon, 21 Jan 2019 14:41:44 -0300
committer: Alvaro Herrera <[email protected]>
date : Mon, 21 Jan 2019 14:41:44 -0300
Per note from Erik Rijkers
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/release-10.sgml
M doc/src/sgml/release-11.sgml
Revert "Fix under-quoted filename pattern in pgbench TAP test."
commit : 93f80cc2d75866cb6c53ce8e1addac47f6b61d67
author : Tom Lane <[email protected]>
date : Mon, 21 Jan 2019 11:28:03 -0500
committer: Tom Lane <[email protected]>
date : Mon, 21 Jan 2019 11:28:03 -0500
This reverts commit 458a1244f1fcf407874482a93b7631ecf5303d6e.
It has portability problems on Windows, which will require
a little bit of research to fix.
Discussion: https://postgr.es/m/[email protected]
M src/bin/pgbench/t/001_pgbench_with_server.pl
Postpone generating tlists and EC members for inheritance dummy children.
commit : b10e3bba86731b53467b33533ca52a1d432163b2
author : Etsuro Fujita <[email protected]>
date : Mon, 21 Jan 2019 17:46:15 +0900
committer: Etsuro Fujita <[email protected]>
date : Mon, 21 Jan 2019 17:46:15 +0900
Previously, in set_append_rel_size(), we generated tlists and EC members
for dummy children for possible use by partition-wise join, even if
partition-wise join was disabled or the top parent was not a partitioned
table, but adding such EC members causes noticeable planning speed
degradation for queries with certain kinds of join quals like
"(foo.x + bar.y) = constant" where foo and bar are partitioned tables in
cases where there are lots of dummy children, as the EC members lists
grow huge, especially for the ECs derived from such join quals, which
makes the search for the parent EC members in add_child_rel_equivalences()
very time-consuming. Postpone the work until such children are actually
involved in a partition-wise join.
Reported-by: Sanyo Capobiango
Analyzed-by: Justin Pryzby and Alvaro Herrera
Author: Amit Langote, with a few additional changes by me
Reviewed-by: Ashutosh Bapat
Backpatch-through: v11 where partition-wise join was added
Discussion: https://postgr.es/m/CAO698qZnrxoZu7MEtfiJmpmUtz3AVYFVnwzR%2BpqjF%3DrmKBTgpw%40mail.gmail.com
M src/backend/optimizer/path/allpaths.c
M src/backend/optimizer/path/joinrels.c
Revert "Add valgrind suppressions for wcsrtombs optimizations"
commit : 0ec29785c52cfd400d3106d6606f150ed2356b11
author : Tomas Vondra <[email protected]>
date : Sat, 19 Jan 2019 20:48:02 +0100
committer: Tomas Vondra <[email protected]>
date : Sat, 19 Jan 2019 20:48:02 +0100
This reverts commit bf070ce09e05943d6484de0ec17c7b02f2690a6d.
Per discussion, it's not desirable to add valgrind suppressions for
outside our own code base (e.g. glibc in this case), especially when
the suppressions may be platform-specific. There are better ways to
deal with that, e.g. by providing local suppressions.
Discussion: https://www.postgresql.org/message-id/flat/90ac0452-e907-e7a4-b3c8-15bd33780e62%402ndquadrant.com
M src/tools/valgrind.supp
Fix outdated comment
commit : 5279c8d097a1346e3dddbed7c0002c735aa23f73
author : Peter Eisentraut <[email protected]>
date : Sat, 19 Jan 2019 09:34:24 +0100
committer: Peter Eisentraut <[email protected]>
date : Sat, 19 Jan 2019 09:34:24 +0100
The issue the comment is referring to was fixed by
08859bb5c2cebc132629ca838113d27bb31b990c.
M src/backend/executor/execReplication.c
Fix under-quoted filename pattern in pgbench TAP test.
commit : e14536f79ea7ab70f0566b2e85c164af6a333829
author : Tom Lane <[email protected]>
date : Fri, 18 Jan 2019 15:23:44 -0500
committer: Tom Lane <[email protected]>
date : Fri, 18 Jan 2019 15:23:44 -0500
Avoids issues if build directory's pathname contains regex
metacharacters.
Raúl Marín Rodríguez
Discussion: https://postgr.es/m/CAM6_UM6dGdU39PKAC24T+HD9ouy0jLN9vH6163K8QEEzr__iZw@mail.gmail.com
M src/bin/pgbench/t/001_pgbench_with_server.pl
Use our own getopt() on OpenBSD.
commit : e4ffa0dcb797d625d590ff25d232d1bbc991aa28
author : Tom Lane <[email protected]>
date : Fri, 18 Jan 2019 15:06:26 -0500
committer: Tom Lane <[email protected]>
date : Fri, 18 Jan 2019 15:06:26 -0500
Recent OpenBSD (at least 5.9 and up) has a version of getopt(3)
that will not cope with the "-:" spec we use to accept double-dash
options in postgres.c and postmaster.c. Admittedly, that's a hack
because POSIX only requires getopt() to allow alphanumeric option
characters. I have no desire to find another way, however, so
let's just do what we were already doing on Solaris: force use
of our own src/port/getopt.c implementation.
In passing, improve some of the comments around said implementation.
Per buildfarm and local testing. Back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M configure
M configure.in
M src/include/pg_getopt.h
M src/port/getopt.c
Fix creation of duplicate foreign keys on partitions
commit : 4dff8935fbab64aef38470424cc57dbda9efa1cf
author : Alvaro Herrera <[email protected]>
date : Fri, 18 Jan 2019 14:49:40 -0300
committer: Alvaro Herrera <[email protected]>
date : Fri, 18 Jan 2019 14:49:40 -0300
When creating a foreign key in a partitioned table, if some partitions
already have equivalent constraints, we wastefully create duplicates of
the constraints instead of attaching to the existing ones. That's
inconsistent with the de-duplication that is applied when a table is
attached as a partition. To fix, reuse the FK-cloning code instead of
having a separate code path.
Backpatch to Postgres 11. This is a subtle behavior change, but surely
a welcome one since there's no use in having duplicate foreign keys.
Discovered by Álvaro Herrera while thinking about a different problem
reported by Jesper Pedersen (bug #15587).
Author: Álvaro Herrera
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/tablecmds.c
M src/test/regress/expected/foreign_key.out
M src/test/regress/sql/foreign_key.sql
Move CloneForeignKeyConstraints to tablecmds.c
commit : fca6cabed17c4960224408d44e3d384b560b78f5
author : Alvaro Herrera <[email protected]>
date : Fri, 18 Jan 2019 14:49:27 -0300
committer: Alvaro Herrera <[email protected]>
date : Fri, 18 Jan 2019 14:49:27 -0300
My commit 3de241dba86f introduced some code to create a clone of a
foreign key to a partition, but I put it in pg_constraint.c because it
was too close to the contents of the pg_constraint row. With the
previous commit that split out the constraint tuple deconstruction into
its own routine, it makes more sense to have the FK-cloning function in
tablecmds.c, mostly because its static subroutine can then be used by a
future bugfix.
My initial posting of this patch had this routine as static in
tablecmds.c, but sadly this function is already part of the Postgres 11
ABI as exported from pg_constraint.c, so keep it as exported also just
to avoid breaking any possible users of it.
M src/backend/catalog/pg_constraint.c
M src/backend/commands/tablecmds.c
M src/include/catalog/pg_constraint.h
M src/include/commands/tablecmds.h
Refactor duplicate code into DeconstructFkConstraintRow
commit : e974f223abb473ba62577261378ca740c641814f
author : Alvaro Herrera <[email protected]>
date : Fri, 18 Jan 2019 14:40:13 -0300
committer: Alvaro Herrera <[email protected]>
date : Fri, 18 Jan 2019 14:40:13 -0300
My commit 3de241dba86f introduced some code (in tablecmds.c) to obtain
data from a pg_constraint row for a foreign key, that already existed in
ri_triggers.c. Split it out into its own routine in pg_constraint.c,
where it naturally belongs.
No functional code changes, only code movement.
Backpatch to pg11, because a future bugfix is simpler after this.
M src/backend/catalog/pg_constraint.c
M src/backend/utils/adt/ri_triggers.c
M src/backend/utils/cache/relcache.c
M src/include/catalog/pg_constraint.h
Enforce non-parallel plan when calling current_schema() in newly-added test
commit : 3daac78d983f7be1c824ce625c8e92f42ebf41fe
author : Michael Paquier <[email protected]>
date : Fri, 18 Jan 2019 10:51:47 +0900
committer: Michael Paquier <[email protected]>
date : Fri, 18 Jan 2019 10:51:47 +0900
current_schema() gets called in the recently-added regression test from
c5660e0, and can be used in a parallel context, causing its call to fail
when creating a temporary schema.
Per buildfarm members crake and lapwing.
Discussion: https://postgr.es/m/[email protected]
M src/test/regress/expected/temp.out
M src/test/regress/sql/temp.sql
Avoid assuming that we know the spelling of getopt_long's error messages.
commit : 43404015955804dd6ff10563f4f78f5f352dbe25
author : Tom Lane <[email protected]>
date : Thu, 17 Jan 2019 19:31:03 -0500
committer: Tom Lane <[email protected]>
date : Thu, 17 Jan 2019 19:31:03 -0500
I've had enough of "fixing" this test case. Whatever value it has
is limited to verifying that pgbench fails for an unrecognized switch,
and we don't need to assume anything about what getopt_long prints in
order to do that.
Discussion: https://postgr.es/m/[email protected]
M src/bin/pgbench/t/002_pgbench_no_server.pl
Restrict the use of temporary namespace in two-phase transactions
commit : 3e4fdb3bc0dc3314a0396bc7067afb40e0df186e
author : Michael Paquier <[email protected]>
date : Fri, 18 Jan 2019 09:21:52 +0900
committer: Michael Paquier <[email protected]>
date : Fri, 18 Jan 2019 09:21:52 +0900
Attempting to use a temporary table within a two-phase transaction is
forbidden for ages. However, there have been uncovered grounds for
a couple of other object types and commands which work on temporary
objects with two-phase commit. In short, trying to create, lock or drop
an object on a temporary schema should not be authorized within a
two-phase transaction, as it would cause its state to create
dependencies with other sessions, causing all sorts of side effects with
the existing session or other sessions spawned later on trying to use
the same temporary schema name.
Regression tests are added to cover all the grounds found, the original
report mentioned function creation, but monitoring closer there are many
other patterns with LOCK, DROP or CREATE EXTENSION which are involved.
One of the symptoms resulting in combining both is that the session
which used the temporary schema is not able to shut down completely,
waiting for being able to drop the temporary schema, something that it
cannot complete because of the two-phase transaction involved with
temporary objects. In this case the client is able to disconnect but
the session remains alive on the backend-side, potentially blocking
connection backend slots from being used. Other problems reported could
also involve server crashes.
This is back-patched down to v10, which is where 9b013dc has introduced
MyXactFlags, something that this patch relies on.
Reported-by: Alexey Bashtanov
Author: Michael Paquier
Reviewed-by: Masahiko Sawada
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 10
M doc/src/sgml/ref/prepare_transaction.sgml
M src/backend/access/transam/xact.c
M src/backend/catalog/namespace.c
M src/backend/commands/dropcmds.c
M src/backend/commands/extension.c
M src/backend/commands/lockcmds.c
M src/include/access/xact.h
M src/test/modules/test_extensions/expected/test_extensions.out
M src/test/modules/test_extensions/sql/test_extensions.sql
M src/test/regress/expected/temp.out
M src/test/regress/sql/temp.sql
Replace references to mailinglists with @lists.postgresql.org
commit : ef2cd88fb0f3a62312bdd33c8f5f36b9b18fc1ac
author : Magnus Hagander <[email protected]>
date : Thu, 17 Jan 2019 13:42:40 +0100
committer: Magnus Hagander <[email protected]>
date : Thu, 17 Jan 2019 13:42:40 +0100
The namespace for all lists have changed a while ago, so all references
should use the correct address.
M doc/src/sgml/installation.sgml
M doc/src/sgml/problems.sgml
M doc/src/sgml/stylesheet-hh.xsl
M doc/src/sgml/stylesheet-html-common.xsl
M doc/src/sgml/xml2.sgml
Remove references to Majordomo
commit : bbccf9a83c22b38f5d8ae061560639e2c06bcded
author : Magnus Hagander <[email protected]>
date : Thu, 17 Jan 2019 13:35:34 +0100
committer: Magnus Hagander <[email protected]>
date : Thu, 17 Jan 2019 13:35:34 +0100
Lists are not handled by Majordomo anymore and haven't been for a while,
so remove the reference and instead direct people to the list server.
M doc/src/sgml/problems.sgml
Postpone aggregate checks until after collation is assigned.
commit : e74d8c5085aaf132be55670e8db5b019c7c3f4d3
author : Andrew Gierth <[email protected]>
date : Thu, 17 Jan 2019 05:33:01 +0000
committer: Andrew Gierth <[email protected]>
date : Thu, 17 Jan 2019 05:33:01 +0000
Previously, parseCheckAggregates was run before
assign_query_collations, but this causes problems if any expression
has already had a collation assigned by some transform function (e.g.
transformCaseExpr) before parseCheckAggregates runs. The differing
collations would cause expressions not to be recognized as equal to
the ones in the GROUP BY clause, leading to spurious errors about
unaggregated column references.
The result was that CASE expr WHEN val ... would fail when "expr"
contained a GROUPING() expression or matched one of the group by
expressions, and where collatable types were involved; whereas the
supposedly identical CASE WHEN expr = val ... would succeed.
Backpatch all the way; this appears to have been wrong ever since
collations were introduced.
Per report from Guillaume Lelarge, analysis and patch by me.
Discussion: https://postgr.es/m/CAECtzeVSO_US8C2Khgfv54ZMUOBR4sWq+6_bLrETnWExHT=rFg@mail.gmail.com
Discussion: https://postgr.es/m/[email protected]
M src/backend/parser/analyze.c
M src/test/regress/expected/aggregates.out
M src/test/regress/expected/groupingsets.out
M src/test/regress/sql/aggregates.sql
M src/test/regress/sql/groupingsets.sql
Fix typos in documentation and for one wait event
commit : 6afea53c30d9ec841d593651ab7ae252801f64c5
author : Michael Paquier <[email protected]>
date : Tue, 15 Jan 2019 08:47:08 +0900
committer: Michael Paquier <[email protected]>
date : Tue, 15 Jan 2019 08:47:08 +0900
These have been found while cross-checking for the use of unique words
in the documentation, and a wait event was not getting generated in a way
consistent to what the documentation provided.
Author: Alexander Lakhin
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/file-fdw.sgml
M doc/src/sgml/func.sgml
M doc/src/sgml/libpq.sgml
M doc/src/sgml/ref/pg_dump.sgml
M src/backend/postmaster/pgstat.c
Fix unique INCLUDE indexes on partitioned tables
commit : 74aa7e046e4a3927d506bc651261724539f67139
author : Alvaro Herrera <[email protected]>
date : Mon, 14 Jan 2019 19:25:19 -0300
committer: Alvaro Herrera <[email protected]>
date : Mon, 14 Jan 2019 19:25:19 -0300
We were considering the INCLUDE columns as part of the key, allowing
unicity-violating rows to be inserted in different partitions.
Concurrent development conflict in eb7ed3f30634 and 8224de4f42cc.
Reported-by: Justin Pryzby
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/indexcmds.c
M src/test/regress/expected/indexing.out
M src/test/regress/sql/indexing.sql
fix typo
commit : 20b4ed8d03047501cc28b600973564850bd1dd80
author : Andrew Dunstan <[email protected]>
date : Sun, 13 Jan 2019 16:43:14 -0500
committer: Andrew Dunstan <[email protected]>
date : Sun, 13 Jan 2019 16:43:14 -0500
M src/Makefile.global.in
Make DLSUFFIX easily discoverable by build scripts
commit : f0566cec3a9fd67d30612afbe6dc4cf602641efa
author : Andrew Dunstan <[email protected]>
date : Sun, 13 Jan 2019 15:59:35 -0500
committer: Andrew Dunstan <[email protected]>
date : Sun, 13 Jan 2019 15:59:35 -0500
This will enable things like the buildfarm client to discover more
reliably if certain libraries have been installed.
Discussion: https://postgr.es/m/[email protected]
Backpatch to all live branches.
M src/Makefile.global.in
Make Emacs perl-mode indent more like perltidy.
commit : 0f514dd78f673080511f9fa7749e6e312a1ddd9b
author : Noah Misch <[email protected]>
date : Sun, 13 Jan 2019 11:32:31 -0800
committer: Noah Misch <[email protected]>
date : Sun, 13 Jan 2019 11:32:31 -0800
This especially helps braces that surround code blocks. Back-patch to
v11, where commit 56fb890ace8ac0ca955ae0803c580c2074f876f6 first
appeared; before that, settings were even more distant from perltidy.
Reviewed by Andrew Dunstan.
Discussion: https://postgr.es/m/[email protected]
M .dir-locals.el
M src/tools/editors/emacs.samples
configure: Update python search order
commit : 3d498c65ac6ed69aa6ede68186420b3c0dadf3c7
author : Peter Eisentraut <[email protected]>
date : Fri, 11 Jan 2019 15:45:15 +0100
committer: Peter Eisentraut <[email protected]>
date : Fri, 11 Jan 2019 15:45:15 +0100
Some systems don't ship with "python" by default anymore, only
"python3" or "python2" or some combination, so include those in the
configure search.
Discussion: https://www.postgresql.org/message-id/flat/1457.1543184081%40sss.pgh.pa.us#c9cc1199338fd6a257589c6dcea6cf8d
M config/python.m4
M configure
M doc/src/sgml/installation.sgml
Fix up confusion over how to use EXTRA_INSTALL.
commit : f285f23970dee5ab9ac67a415a41a3a19010be87
author : Tom Lane <[email protected]>
date : Fri, 11 Jan 2019 17:39:30 -0500
committer: Tom Lane <[email protected]>
date : Fri, 11 Jan 2019 17:39:30 -0500
Some makefiles were trying to do this:
temp-install: EXTRA_INSTALL=contrib/test_decoding
but that no longer works as of commit aa019da52: the macro is now
consulted by the checkprep target, one level down, and apparently
gmake doesn't propagate such macro settings recursively.
The problem is masked since 42e61c774 because pgxs.mk also sets up
EXTRA_INSTALL, and correctly applies it to the checkprep target.
Unfortunately I'd not risked back-patching that to before v11.
Since aa019da52 was pushed back to v10, it broke test_decoding
there (the only module for which this actually makes a difference
at present).
Hence, back-patch 42e61c774 to v10. Also, remove some demonstrably
useless settings of EXTRA_INSTALL in v10 and v11 (they'd already
been cleaned up in HEAD).
Per buildfarm.
Discussion: https://postgr.es/m/CAEepm=1pEJdwv6DSGmOfpX0EaX7L7sT28c1nXpqvQvmLfEWb1g@mail.gmail.com
M contrib/test_decoding/Makefile
M src/test/modules/snapshot_too_old/Makefile
Free pre-modification HeapTuple in ALTER TABLE ... TYPE ...
commit : 89d52b9a3e3fab3d6876c997370684a8b1c77f3b
author : Andrew Dunstan <[email protected]>
date : Fri, 11 Jan 2019 17:12:54 -0500
committer: Andrew Dunstan <[email protected]>
date : Fri, 11 Jan 2019 17:12:54 -0500
This was an oversight in commit 3b174b1a3.
Per offline gripe from Alvaro Herrera
Backpatch to release 11.
M src/backend/commands/tablecmds.c
Avoid sharing PARAM_EXEC slots between different levels of NestLoop.
commit : 05eb923eae46c1698088d555ae590a73d4fc7070
author : Tom Lane <[email protected]>
date : Fri, 11 Jan 2019 15:53:34 -0500
committer: Tom Lane <[email protected]>
date : Fri, 11 Jan 2019 15:53:34 -0500
Up to now, createplan.c attempted to share PARAM_EXEC slots for
NestLoopParams across different plan levels, if the same underlying Var
was being fed down to different righthand-side subplan trees by different
NestLoops. This was, I think, more of an artifact of using subselect.c's
PlannerParamItem infrastructure than an explicit design goal, but anyway
that was the end result.
This works well enough as long as the plan tree is executing synchronously,
but the feature whereby Gather can execute the parallelized subplan locally
breaks it. An upper NestLoop node might execute for a row retrieved from
a parallel worker, and assign a value for a PARAM_EXEC slot from that row,
while the leader's copy of the parallelized subplan is suspended with a
different active value of the row the Var comes from. When control
eventually returns to the leader's subplan, it gets the wrong answers if
the same PARAM_EXEC slot is being used within the subplan, as reported
in bug #15577 from Bartosz Polnik.
This is pretty reminiscent of the problem fixed in commit 46c508fbc, and
the proper fix seems to be the same: don't try to share PARAM_EXEC slots
across different levels of controlling NestLoop nodes.
This requires decoupling NestLoopParam handling from PlannerParamItem
handling, although the logic remains somewhat similar. To avoid bizarre
division of labor between subselect.c and createplan.c, I decided to move
all the param-slot-assignment logic for both cases out of those files
and put it into a new file paramassign.c. Hopefully it's a bit better
documented now, too.
A regression test case for this might be nice, but we don't know a
test case that triggers the problem with a suitably small amount
of data.
Back-patch to 9.6 where we added Gather nodes. It's conceivable that
related problems exist in older branches; but without some evidence
for that, I'll leave the older branches alone.
Discussion: https://postgr.es/m/[email protected]
M src/backend/optimizer/plan/createplan.c
M src/backend/optimizer/plan/planner.c
M src/backend/optimizer/plan/subselect.c
M src/backend/optimizer/util/Makefile
A src/backend/optimizer/util/paramassign.c
A src/include/optimizer/paramassign.h
M src/include/optimizer/subselect.h
doc: Correct documentation of install-time environment variables
commit : c559d8dbf9e7871c64ecc976199cc89765a6cee8
author : Peter Eisentraut <[email protected]>
date : Fri, 11 Jan 2019 17:21:45 +0100
committer: Peter Eisentraut <[email protected]>
date : Fri, 11 Jan 2019 17:21:45 +0100
Since approximately PostgreSQL 10, it is no longer required that
environment variables at installation time such as PERL, PYTHON, TCLSH
be "full path names", so change that phrasing in the installation
instructions. (The exact time of change appears to differ for PERL
and the others, but it works consistently in PostgreSQL 10.)
Also while we're here document the defaults for PERL and PYTHON, but
since the search list for TCLSH is so long, let's leave that out so we
don't need to maintain a copy of that list in the installation
instructions.
M doc/src/sgml/installation.sgml
Fix missing values when doing ALTER TABLE ALTER COLUMN TYPE
commit : 076ffbcb5f45eeffb20940842e0f45bdcb4a32fc
author : Andrew Dunstan <[email protected]>
date : Thu, 10 Jan 2019 15:53:45 -0500
committer: Andrew Dunstan <[email protected]>
date : Thu, 10 Jan 2019 15:53:45 -0500
This was an oversight in commit 16828d5c. If the table is going to be
rewritten, we simply clear all the missing values from all the table's
attributes, since there will no longer be any rows with the attributes
missing. Otherwise, we repackage the missing value in an array
constructed with the new type specifications.
Backpatch to release 11.
This fixes bug #15446, reported by Dmitry Molotkov
Reviewed by Dean Rasheed
M src/backend/commands/tablecmds.c
M src/test/regress/expected/fast_default.out
M src/test/regress/sql/fast_default.sql
Update docs & tests to reflect that unassigned OLD/NEW are now NULL.
commit : 312d21d8635065c14d392b4e5469e7abc03f2bde
author : Tom Lane <[email protected]>
date : Wed, 9 Jan 2019 11:35:14 -0500
committer: Tom Lane <[email protected]>
date : Wed, 9 Jan 2019 11:35:14 -0500
For a long time, plpgsql has allowed trigger functions to parse
references to OLD and NEW even if the current trigger event type didn't
assign a value to one or the other variable; but actually executing such
a reference would fail. The v11 changes to use "expanded records" for
DTYPE_REC variables changed the behavior so that the unassigned variable
now reads as a null composite value. While this behavioral change was
more or less unintentional, it seems that leaving it like this is better
than adding code and complexity to be bug-compatible with the old way.
The change doesn't break any code that worked before, and it eliminates
a gotcha that often required extra code to work around.
Hence, update the docs to say that these variables are "null" not
"unassigned" when not relevant to the event type. And add a regression
test covering the behavior, so that we'll notice if we ever break it
again.
Per report from Kristjan Tammekivi.
Discussion: https://postgr.es/m/CAABK7uL-uC9ZxKBXzo_68pKt7cECfNRv+c35CXZpjq6jCAzYYA@mail.gmail.com
M doc/src/sgml/plpgsql.sgml
M doc/src/sgml/release-11.sgml
M src/pl/plpgsql/src/Makefile
A src/pl/plpgsql/src/expected/plpgsql_trigger.out
M src/pl/plpgsql/src/pl_exec.c
A src/pl/plpgsql/src/sql/plpgsql_trigger.sql
Doc: update our docs about kernel IPC parameters on *BSD.
commit : f2e14c2a69147927b7ba090a7ba5a13b2b2b7d5f
author : Tom Lane <[email protected]>
date : Tue, 8 Jan 2019 12:03:53 -0500
committer: Tom Lane <[email protected]>
date : Tue, 8 Jan 2019 12:03:53 -0500
runtime.sgml said that you couldn't change SysV IPC parameters on OpenBSD
except by rebuilding the kernel. That's definitely wrong in OpenBSD 6.x,
and excavation in their man pages says it changed in OpenBSD 3.3.
Update NetBSD and OpenBSD sections to recommend adjustment of the SEMMNI
and SEMMNS settings, which are painfully small by default on those
platforms. (The discussion thread contemplated recommending that
people select POSIX semaphores instead, but the performance consequences
of that aren't really clear, so I'll refrain.)
Remove pointless discussion of SEMMNU and SEMMAP from the FreeBSD
section. Minor other wordsmithing.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/runtime.sgml
Doc: fix meaning of acronym "btree".
commit : 6ce6d983224a8cf00ff34bb3dd6c9d734d9bae86
author : Tatsuo Ishii <[email protected]>
date : Tue, 8 Jan 2019 09:55:18 +0900
committer: Tatsuo Ishii <[email protected]>
date : Tue, 8 Jan 2019 09:55:18 +0900
Acronym "btree" better means "multi-way balanced tree" rather than
"multi-way binary tree".
Discussion: https://postgr.es/m/20190105.183532.1686260542006440682.t-ishii%40sraoss.co.jp
M doc/src/sgml/btree.sgml
doc: document that INFO messages always go to client.
commit : 7de8c719d3becdb4dcbefbae53c03c588a0ea699
author : Andrew Gierth <[email protected]>
date : Mon, 7 Jan 2019 18:19:46 +0000
committer: Andrew Gierth <[email protected]>
date : Mon, 7 Jan 2019 18:19:46 +0000
In passing add a couple of links to the message severity table.
Backpatch because it's always been this way.
Author: Karl O. Pinc <[email protected]>
M doc/src/sgml/config.sgml
Improve ANALYZE's handling of concurrent-update scenarios.
commit : fc8adddd9af24737e46006dcdf12b98c3e195fd7
author : Tom Lane <[email protected]>
date : Thu, 3 Jan 2019 17:00:08 -0500
committer: Tom Lane <[email protected]>
date : Thu, 3 Jan 2019 17:00:08 -0500
This patch changes the rule for whether or not a tuple seen by ANALYZE
should be included in its sample.
When we last touched this logic, in commit 51e1445f1, we weren't
thinking very hard about tuples being UPDATEd by a long-running
concurrent transaction. In such a case, we might see the pre-image as
either LIVE or DELETE_IN_PROGRESS depending on timing; and we might see
the post-image not at all, or as INSERT_IN_PROGRESS. Since the existing
code will not sample either DELETE_IN_PROGRESS or INSERT_IN_PROGRESS
tuples, this leads to concurrently-updated rows being omitted from the
sample entirely. That's not very helpful, and it's especially the wrong
thing if the concurrent transaction ends up rolling back.
The right thing seems to be to sample DELETE_IN_PROGRESS rows just as if
they were live. This makes the "sample it" and "count it" decisions the
same, which seems good for consistency. It's clearly the right thing
if the concurrent transaction ends up rolling back; in effect, we are
sampling as though IN_PROGRESS transactions haven't happened yet.
Also, this combination of choices ensures maximum robustness against
the different combinations of whether and in which state we might see the
pre- and post-images of an update.
It's slightly annoying that we end up recording immediately-out-of-date
stats in the case where the transaction does commit, but on the other
hand the stats are fine for columns that didn't change in the update.
And the alternative of sampling INSERT_IN_PROGRESS rows instead seems
like a bad idea, because then the sampling would be inconsistent with
the way rows are counted for the stats report.
Per report from Mark Chambers; thanks to Jeff Janes for diagnosing
what was happening. Back-patch to all supported versions.
Discussion: https://postgr.es/m/CAFh58O_Myr6G3tcH3gcGrF-=OExB08PJdWZcSBcEcovaiPsrHA@mail.gmail.com
M src/backend/commands/analyze.c
Update ssl test certificates and keys
commit : 1b0294d9a02cf77392fe71387813a0614a808782
author : Peter Eisentraut <[email protected]>
date : Thu, 3 Jan 2019 15:06:53 +0100
committer: Peter Eisentraut <[email protected]>
date : Thu, 3 Jan 2019 15:06:53 +0100
Debian testing and newer now require that RSA and DHE keys are at
least 2048 bit long and no longer allow SHA-1 for signatures in
certificates. This is currently causing the ssl tests to fail there
because the test certificates and keys have been created in violation
of those conditions.
Update the parameters to create the test files and create a new set of
test files.
Author: Kyotaro HORIGUCHI <[email protected]>
Reported-by: Michael Paquier <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/20180917131340.GE31460%40paquier.xyz
M src/test/ssl/Makefile
M src/test/ssl/cas.config
M src/test/ssl/ssl/both-cas-1.crt
M src/test/ssl/ssl/both-cas-2.crt
M src/test/ssl/ssl/client+client_ca.crt
M src/test/ssl/ssl/client-revoked.crt
M src/test/ssl/ssl/client-revoked.key
M src/test/ssl/ssl/client.crl
M src/test/ssl/ssl/client.crt
M src/test/ssl/ssl/client.key
M src/test/ssl/ssl/client_ca.crt
M src/test/ssl/ssl/client_ca.key
M src/test/ssl/ssl/root+client.crl
M src/test/ssl/ssl/root+client_ca.crt
M src/test/ssl/ssl/root+server.crl
M src/test/ssl/ssl/root+server_ca.crt
M src/test/ssl/ssl/root.crl
M src/test/ssl/ssl/root_ca.crt
M src/test/ssl/ssl/root_ca.key
M src/test/ssl/ssl/server-cn-and-alt-names.crt
M src/test/ssl/ssl/server-cn-and-alt-names.key
M src/test/ssl/ssl/server-cn-only.crt
M src/test/ssl/ssl/server-cn-only.key
M src/test/ssl/ssl/server-multiple-alt-names.crt
M src/test/ssl/ssl/server-multiple-alt-names.key
M src/test/ssl/ssl/server-no-names.crt
M src/test/ssl/ssl/server-no-names.key
M src/test/ssl/ssl/server-password.key
M src/test/ssl/ssl/server-revoked.crt
M src/test/ssl/ssl/server-revoked.key
M src/test/ssl/ssl/server-single-alt-name.crt
M src/test/ssl/ssl/server-single-alt-name.key
M src/test/ssl/ssl/server-ss.crt
M src/test/ssl/ssl/server-ss.key
M src/test/ssl/ssl/server.crl
M src/test/ssl/ssl/server_ca.crt
M src/test/ssl/ssl/server_ca.key
Don't believe MinMaxExpr is leakproof without checking.
commit : 099063340bb1f82cc3e156e5558f6c456b41bfa5
author : Tom Lane <[email protected]>
date : Wed, 2 Jan 2019 16:33:48 -0500
committer: Tom Lane <[email protected]>
date : Wed, 2 Jan 2019 16:33:48 -0500
MinMaxExpr invokes the btree comparison function for its input datatype,
so it's only leakproof if that function is. Many such functions are
indeed leakproof, but others are not, and we should not just assume that
they are. Hence, adjust contain_leaked_vars to verify the leakproofness
of the referenced function explicitly.
I didn't add a regression test because it would need to depend on
some particular comparison function being leaky, and that's a moving
target, per discussion.
This has been wrong all along, so back-patch to supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/optimizer/util/clauses.c
Update copyright for 2019
commit : 7cf8879fe61e330aa55154b16b750bb19d6c6e97
author : Bruce Momjian <[email protected]>
date : Wed, 2 Jan 2019 12:44:25 -0500
committer: Bruce Momjian <[email protected]>
date : Wed, 2 Jan 2019 12:44:25 -0500
Backpatch-through: certain files through 9.4
M COPYRIGHT
M doc/src/sgml/legal.sgml
Fix generation of padding message before encrypting Elgamal in pgcrypto
commit : 2882bab920a41186ed9ec719947b1e730fd335a8
author : Michael Paquier <[email protected]>
date : Tue, 1 Jan 2019 10:39:29 +0900
committer: Michael Paquier <[email protected]>
date : Tue, 1 Jan 2019 10:39:29 +0900
fe0a0b5, which has added a stronger random source in Postgres, has
introduced a thinko when creating a padding message which gets encrypted
for Elgamal. The padding message cannot have zeros, which are replaced
by random bytes. However if pg_strong_random() failed, the message
would finish by being considered in correct shape for encryption with
zeros.
Author: Tom Lane
Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 10
M contrib/pgcrypto/pgp-pubenc.c
Process EXTRA_INSTALL serially, during the first temp-install.
commit : 6dd690be366148ad0cd9a7f99ca094d89aa76f02
author : Noah Misch <[email protected]>
date : Mon, 31 Dec 2018 13:54:38 -0800
committer: Noah Misch <[email protected]>
date : Mon, 31 Dec 2018 13:54:38 -0800
This closes a race condition in "make -j check-world"; the symptom was
EEXIST errors. Back-patch to v10, before which parallel check-world had
worse problems.
Discussion: https://postgr.es/m/[email protected]
M GNUmakefile.in
M src/Makefile.global.in
M src/makefiles/pgxs.mk
Send EXTRA_INSTALL errors to install.log, not stderr.
commit : 95fae739af68b27c5c555ffe10c4c98f2a6a3cdd
author : Noah Misch <[email protected]>
date : Mon, 31 Dec 2018 13:53:05 -0800
committer: Noah Misch <[email protected]>
date : Mon, 31 Dec 2018 13:53:05 -0800
We already redirected other temp-install stderr and all temp-install
stdout in this way. Back-patch to v10, like the next commit.
Discussion: https://postgr.es/m/[email protected]
M src/Makefile.global.in
pg_regress: Promptly detect failed postmaster startup.
commit : ca01a6748d0bfb594128833fec6a64e6d092d37f
author : Noah Misch <[email protected]>
date : Mon, 31 Dec 2018 13:50:32 -0800
committer: Noah Misch <[email protected]>
date : Mon, 31 Dec 2018 13:50:32 -0800
Detect it the way pg_ctl's wait_for_postmaster() does. When pg_regress
spawned a postmaster that failed startup, we were detecting that only
with "pg_regress: postmaster did not respond within 60 seconds".
Back-patch to 9.4 (all supported versions).
Reviewed by Tom Lane.
Discussion: https://postgr.es/m/[email protected]
M src/test/regress/pg_regress.c
pg_rewind: Add missing newline to error message
commit : 025cc86b77052ee130519ce2dcfa52abeedc5bef
author : Peter Eisentraut <[email protected]>
date : Sat, 29 Dec 2018 13:02:51 +0100
committer: Peter Eisentraut <[email protected]>
date : Sat, 29 Dec 2018 13:02:51 +0100
M src/bin/pg_rewind/pg_rewind.c
Improve description of DEFAULT_XLOG_SEG_SIZE in pg_config.h
commit : 6a19384e74a8d8510d06e85b3956136bd30d4733
author : Michael Paquier <[email protected]>
date : Sat, 29 Dec 2018 08:24:47 +0900
committer: Michael Paquier <[email protected]>
date : Sat, 29 Dec 2018 08:24:47 +0900
This was incorrectly referring to --walsegsize, and its description is
rewritten in a clearer way.
Author: Ian Barwick, Tom Lane
Reviewed-by: Álvaro Herrera, Michael Paquier
Discussion: https://postgr.es/m/[email protected]
M src/include/pg_config_manual.h
Fix latent problem with pg_jrand48().
commit : d58e01f8abe2de106516073b39391c466aaab5f6
author : Tom Lane <[email protected]>
date : Fri, 28 Dec 2018 14:08:24 -0500
committer: Tom Lane <[email protected]>
date : Fri, 28 Dec 2018 14:08:24 -0500
POSIX specifies that jrand48() returns a signed 32-bit value (in the
range [-2^31, 2^31)), but our code was returning an unsigned 32-bit
value (in the range [0, 2^32)). This doesn't actually matter to any
existing call site, because they all cast the "long" result to int32
or uint32; but it will doubtless bite somebody in the future.
To fix, cast the arithmetic result to int32 explicitly before the
compiler widens it to long (if widening is needed).
While at it, upgrade this file's far-short-of-project-style comments.
Had there been some peer pressure to document pg_jrand48() properly,
maybe this thinko wouldn't have gotten committed to begin with.
Backpatch to v10 where pg_jrand48() was added, just in case somebody
back-patches a fix that uses it and depends on the standard behavior.
Discussion: https://postgr.es/m/[email protected]
M src/port/erand48.c
Reduce length of GIN predicate locking isolation test suite
commit : fcdda202bcf8fa71e1b919f62d3bb96f610ff25f
author : Alexander Korotkov <[email protected]>
date : Fri, 28 Dec 2018 03:33:10 +0300
committer: Alexander Korotkov <[email protected]>
date : Fri, 28 Dec 2018 03:33:10 +0300
Isolation test suite of GIN predicate locking was criticized for being too slow,
especially under Valgrind. This commit is intended to accelerate it. Tests are
simplified in the following ways.
1) Amount of data is reduced. We're now close to the minimal amount of data,
which produces at least one posting tree and at least two pages of entry
tree.
2) Three isolation tests are merged into one.
3) Only one tuple is queried from posting tree. So, locking of index is the
same, but tuple locks are not propagated to relation lock. Also, it is
faster.
4) Test cases itself are simplified. Now each test case run just one INSERT
and one SELECT involving GIN, which either conflict or not.
Discussion: https://postgr.es/m/20181204000740.ok2q53nvkftwu43a%40alap3.anarazel.de
Reported-by: Andres Freund
Tested-by: Andrew Dunstan
Author: Alexander Korotkov
Backpatch-through: 11
D src/test/isolation/expected/predicate-gin-fastupdate.out
D src/test/isolation/expected/predicate-gin-nomatch.out
M src/test/isolation/expected/predicate-gin.out
M src/test/isolation/isolation_schedule
D src/test/isolation/specs/predicate-gin-fastupdate.spec
D src/test/isolation/specs/predicate-gin-nomatch.spec
M src/test/isolation/specs/predicate-gin.spec
Remove entry tree root conflict checking from GIN predicate locking
commit : fd7c081955929df343318d6c5d32ea24a574aacf
author : Alexander Korotkov <[email protected]>
date : Thu, 27 Dec 2018 04:10:51 +0300
committer: Alexander Korotkov <[email protected]>
date : Thu, 27 Dec 2018 04:10:51 +0300
According to README we acquire predicate locks on entry tree leafs and posting
tree roots. However, when ginFindLeafPage() is going to lock leaf in exclusive
mode, then it checks root for conflicts regardless whether it's a entry or
posting tree. Assuming that we never place predicate lock on entry tree root
(excluding corner case when root is leaf), this check is redundant. This
commit removes this check. Now, root conflict checking is controlled by
separate argument of ginFindLeafPage().
Discussion: https://postgr.es/m/CAPpHfdv7rrDyy%3DMgsaK-L9kk0AH7az0B-mdC3w3p0FSb9uoyEg%40mail.gmail.com
Author: Alexander Korotkov
Backpatch-through: 11
M src/backend/access/gin/ginbtree.c
M src/backend/access/gin/gindatapage.c
M src/backend/access/gin/ginget.c
M src/backend/access/gin/gininsert.c
M src/include/access/gin_private.h
Ignore inherited temp relations from other sessions when truncating
commit : b30b9dce1f40499949fd3749265acf1b379102dc
author : Michael Paquier <[email protected]>
date : Thu, 27 Dec 2018 10:17:09 +0900
committer: Michael Paquier <[email protected]>
date : Thu, 27 Dec 2018 10:17:09 +0900
Inheritance trees can include temporary tables if the parent is
permanent, which makes possible the presence of multiple temporary
children from different sessions. Trying to issue a TRUNCATE on the
parent in this scenario causes a failure, so similarly to any other
queries just ignore such cases, which makes TRUNCATE work
transparently.
This makes truncation behave similarly to any other DML query working on
the parent table with queries which need to be issues on children. A
set of isolation tests is added to cover basic cases.
Reported-by: Zhou Digoal
Author: Amit Langote, Michael Paquier
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4
M src/backend/commands/tablecmds.c
A src/test/isolation/expected/inherit-temp.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/inherit-temp.spec
Fix portability failure introduced in commits d2b0b60e7 et al.
commit : 47c93ace9fd1e3ed90defb3a478ad2287342b22d
author : Tom Lane <[email protected]>
date : Wed, 26 Dec 2018 15:30:10 -0500
committer: Tom Lane <[email protected]>
date : Wed, 26 Dec 2018 15:30:10 -0500
I made a frontend fprintf() format use %m, forgetting that that's only
safe in HEAD not the back branches; prior to 96bf88d52 and d6c55de1f,
it would work on glibc platforms but not elsewhere. Revert to using
%s ... strerror(errno) as the code did before.
We could have left HEAD as-is, but for code consistency across branches,
I chose to apply this patch there too.
Per Coverity and a few buildfarm members.
M src/common/psprintf.c
Prioritize history files when archiving
commit : a016f59d5901ce37f28e58b622169b579258c2e0
author : Michael Paquier <[email protected]>
date : Mon, 24 Dec 2018 20:25:49 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 24 Dec 2018 20:25:49 +0900
At the end of recovery for the post-promotion process, a new history
file is created followed by the last partial segment of the previous
timeline. Based on the timing, the archiver would first try to archive
the last partial segment and then the history file. This can delay the
detection of a new timeline taken, particularly depending on the time it
takes to transfer the last partial segment as it delays the moment the
history file of the new timeline gets archived. This can cause promoted
standbys to use the same timeline as one already taken depending on the
circumstances if multiple instances look at archives at the same
location.
This commit changes the order of archiving so as history files are
archived in priority over other file types, which reduces the likelihood
of the same timeline being taken (still not reducing the window to
zero), and it makes the archiver behave more consistently with the
startup process doing its post-promotion business.
Author: David Steele
Reviewed-by: Michael Paquier, Kyotaro Horiguchi
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.5
M src/backend/postmaster/pgarch.c
Disable WAL-skipping optimization for COPY on views and foreign tables
commit : ff9c222669063d7a17b179bc19617caf9c1f67ea
author : Michael Paquier <[email protected]>
date : Sun, 23 Dec 2018 16:43:47 +0900
committer: Michael Paquier <[email protected]>
date : Sun, 23 Dec 2018 16:43:47 +0900
COPY can skip writing WAL when loading data on a table which has been
created in the same transaction as the one loading the data, however
this cannot work on views or foreign table as this would result in
trying to flush relation files which do not exist. So disable the
optimization so as commands are able to work the same way with any
configuration of wal_level.
Tests are added to cover the different cases, which need to have
wal_level set to minimal to allow the problem to show up, and that is
not the default configuration.
Reported-by: Luis M. Carril, Etsuro Fujita
Author: Amit Langote, Michael Paquier
Reviewed-by: Etsuro Fujita
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 10, where support for COPY on views has been added,
while v11 has added support for COPY on foreign tables.
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/sql/postgres_fdw.sql
M src/backend/commands/copy.c
M src/test/regress/expected/copy2.out
M src/test/regress/sql/copy2.sql
Fix ancient compiler warnings and typos in !HAVE_SYMLINK code
commit : 018923ccc1a68eeac852edeac2ba3bc91dcbd494
author : Peter Eisentraut <[email protected]>
date : Sat, 22 Dec 2018 07:21:40 +0100
committer: Peter Eisentraut <[email protected]>
date : Sat, 22 Dec 2018 07:21:40 +0100
This has never been correct since this code was introduced.
M src/bin/initdb/initdb.c
M src/bin/pg_basebackup/pg_basebackup.c
Check for conflicting queries during replay of gistvacuumpage()
commit : 8193d64072c46e75fe94065111099ee3b2658769
author : Alexander Korotkov <[email protected]>
date : Fri, 21 Dec 2018 02:37:31 +0300
committer: Alexander Korotkov <[email protected]>
date : Fri, 21 Dec 2018 02:37:31 +0300
013ebc0a7b implements so-called GiST microvacuum. That is gistgettuple() marks
index tuples as dead when kill_prior_tuple is set. Later, when new tuple
insertion claims page space, those dead index tuples are physically deleted
from page. When this deletion is replayed on standby, it might conflict with
read-only queries. But 013ebc0a7b doesn't handle this. That may lead to
disappearance of some tuples from read-only snapshots on standby.
This commit implements resolving of conflicts between replay of GiST microvacuum
and standby queries. On the master we implement new WAL record type
XLOG_GIST_DELETE, which comprises necessary information. On stable releases
we've to be tricky to keep WAL compatibility. Information required for conflict
processing is just appended to data of XLOG_GIST_PAGE_UPDATE record. So,
PostgreSQL version, which doesn't know about conflict processing, will just
ignore that.
Reported-by: Andres Freund
Diagnosed-by: Andres Freund
Discussion: https://postgr.es/m/20181212224524.scafnlyjindmrbe6%40alap3.anarazel.de
Author: Alexander Korotkov
Backpatch-through: 9.6
M src/backend/access/gist/gist.c
M src/backend/access/gist/gistbuild.c
M src/backend/access/gist/gistvacuum.c
M src/backend/access/gist/gistxlog.c
M src/include/access/gist_private.h
Fix lock level used for partition when detaching it
commit : 053ad56d275d343b407bc5fd389bad6f3e340562
author : Alvaro Herrera <[email protected]>
date : Thu, 20 Dec 2018 16:42:13 -0300
committer: Alvaro Herrera <[email protected]>
date : Thu, 20 Dec 2018 16:42:13 -0300
For probably bogus reasons, we acquire only AccessShareLock on the
partition when we try to detach it from its parent partitioned table.
This can cause ugly things to happen if another transaction is doing
any sort of DDL to the partition concurrently.
Upgrade that lock to ShareUpdateExclusiveLock, which per discussion
seems to be the minimum needed.
Reported by Robert Haas.
Discussion: https://postgr.es/m/CA+TgmoYruJQ+2qnFLtF1xQtr71pdwgfxy3Ziy-TxV28M6pEmyA@mail.gmail.com
M src/backend/commands/tablecmds.c
Doc: fix ancient mistake in search_path documentation.
commit : 4e4c0d66866c0d54ec33ef987204cdec729a741b
author : Tom Lane <[email protected]>
date : Thu, 20 Dec 2018 13:55:11 -0500
committer: Tom Lane <[email protected]>
date : Thu, 20 Dec 2018 13:55:11 -0500
"$user" in a search_path string is replaced by CURRENT_USER not
SESSION_USER. (It actually was SESSION_USER in the initial implementation,
but we changed it shortly later, and evidently forgot to fix the docs to
match.)
Noted by [email protected]
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/config.sgml
DETACH PARTITION: hold locks on indexes until end of transaction
commit : 9bb2ce5ec765e2c886af369fa3ba57f98db014e3
author : Alvaro Herrera <[email protected]>
date : Thu, 20 Dec 2018 10:58:22 -0300
committer: Alvaro Herrera <[email protected]>
date : Thu, 20 Dec 2018 10:58:22 -0300
When a partition is detached from its parent, we acquire locks on all
attached indexes to also detach them ... but we release those locks
immediately. This is a violation of the policy of keeping locks on user
objects to the end of the transaction. Bug introduced in 8b08f7d4820f.
It's unclear that there are any ill effects possible, but it's clearly
wrong nonetheless. It's likely that bad behavior *is* possible, but
mostly because the relation that the index is for is only locked with
AccessShareLock, which is an older bug that shall be fixed separately.
While touching that line of code, close the index opened with
index_open() using index_close() instead of relation_close().
No difference in practice, but let's be consistent.
Unearthed by Robert Haas.
Discussion: https://postgr.es/m/CA+TgmoYruJQ+2qnFLtF1xQtr71pdwgfxy3Ziy-TxV28M6pEmyA@mail.gmail.com
M src/backend/commands/tablecmds.c
Fix ADD IF NOT EXISTS used in conjunction with ALTER TABLE ONLY
commit : 128ce8e1a18ed7a83dd0f8dbe7bfb00eb73f200b
author : Greg Stark <[email protected]>
date : Wed, 19 Dec 2018 18:28:35 -0500
committer: Greg Stark <[email protected]>
date : Wed, 19 Dec 2018 18:28:35 -0500
The flag for IF NOT EXISTS was only being passed down in the normal
recursing case. It's been this way since originally added in 9.6 in
commit 2cd40adb85 so backpatch back to 9.6.
M src/backend/commands/tablecmds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Doc: fix incorrect example of collecting arguments with fmgr macros.
commit : c9a1c55a8b342cd00ffa810dfa63620ce6d497da
author : Tom Lane <[email protected]>
date : Wed, 19 Dec 2018 11:02:07 -0500
committer: Tom Lane <[email protected]>
date : Wed, 19 Dec 2018 11:02:07 -0500
Thinko in commit f66912b0a. Back-patch to v10, as that was.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/spi.sgml
Correct obsolete nbtree recovery comments.
commit : 741c4c41429b72b8140a269f578f5a87e03d6ab6
author : Peter Geoghegan <[email protected]>
date : Tue, 18 Dec 2018 16:59:49 -0800
committer: Peter Geoghegan <[email protected]>
date : Tue, 18 Dec 2018 16:59:49 -0800
Commit 40dae7ec537, which made the handling of interrupted nbtree page
splits more robust, removed an nbtree-specific end-of-recovery cleanup
step. This meant that it was no longer possible to complete an
interrupted page split during recovery. However, a reference to
recovery as a reason for using a NULL stack while inserting into a
parent page was missed. Remove the reference.
Remove a similar obsolete reference to recovery that was introduced much
more recently, as part of the btree fastpath optimization enhancement
that made it into Postgres 11 (commit 2b272734, and follow-up commits).
Backpatch: 11-, where the fastpath optimization was introduced.
M src/backend/access/nbtree/nbtinsert.c
Doc: fix typo in "Generic File Access Functions" section.
commit : 84fcc2ce56962a82e4da633b5ba2bd68c4960cd8
author : Tatsuo Ishii <[email protected]>
date : Wed, 19 Dec 2018 09:45:10 +0900
committer: Tatsuo Ishii <[email protected]>
date : Wed, 19 Dec 2018 09:45:10 +0900
Issue reported by me and fix by Tom Lane.
Discussion: https://postgr.es/m/20181219.080458.1434575730369741406.t-ishii%40sraoss.co.jp
M doc/src/sgml/func.sgml
Fix ancient thinko in mergejoin cost estimation.
commit : ad425aaf06c1059a6666180a69f3a76f8343b278
author : Tom Lane <[email protected]>
date : Tue, 18 Dec 2018 11:19:38 -0500
committer: Tom Lane <[email protected]>
date : Tue, 18 Dec 2018 11:19:38 -0500
"rescanratio" was computed as 1 + rescanned-tuples / total-inner-tuples,
which is sensible if it's to be multiplied by total-inner-tuples or a cost
value corresponding to scanning all the inner tuples. But in reality it
was (mostly) multiplied by inner_rows or a related cost, numbers that take
into account the possibility of stopping short of scanning the whole inner
relation thanks to a limited key range in the outer relation. This'd
still make sense if we could expect that stopping short would result in a
proportional decrease in the number of tuples that have to be rescanned.
It does not, however. The argument that establishes the validity of our
estimate for that number is independent of whether we scan all of the inner
relation or stop short, and experimentation also shows that stopping short
doesn't reduce the number of rescanned tuples. So the correct calculation
is 1 + rescanned-tuples / inner_rows, and we should be sure to multiply
that by inner_rows or a corresponding cost value.
Most of the time this doesn't make much difference, but if we have
both a high rescan rate (due to lots of duplicate values) and an outer
key range much smaller than the inner key range, then the error can
be significant, leading to a large underestimate of the cost associated
with rescanning.
Per report from Vijaykumar Jain. This thinko appears to go all the way
back to the introduction of the rescan estimation logic in commit
70fba7043, so back-patch to all supported branches.
Discussion: https://postgr.es/m/CAE7uO5hMb_TZYJcZmLAgO6iD68AkEK6qCe7i=vZUkCpoKns+EQ@mail.gmail.com
M src/backend/optimizer/path/costsize.c
Update project link of pgBadger in documentation
commit : da1a20a68e2e4d3f8c3d841f5ba994ab13f9cb23
author : Michael Paquier <[email protected]>
date : Tue, 18 Dec 2018 10:02:39 +0900
committer: Michael Paquier <[email protected]>
date : Tue, 18 Dec 2018 10:02:39 +0900
The project has moved to a new place.
Reported-by: Peter Neave
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/maintenance.sgml
Include ALTER INDEX SET STATISTICS in pg_dump
commit : d0960eb8ab78f098beb1de2628229ac992da055c
author : Michael Paquier <[email protected]>
date : Tue, 18 Dec 2018 09:28:56 +0900
committer: Michael Paquier <[email protected]>
date : Tue, 18 Dec 2018 09:28:56 +0900
The new grammar pattern of ALTER INDEX SET STATISTICS able to use column
numbers on top of the existing column names introduced by commit 5b6d13e
forgot to add support for the feature in pg_dump, so defining statistics
on index columns was missing from the dumps, potentially causing silent
planning problems with a subsequent restore.
pg_dump ought to not use column names in what it generates as these are
automatically generated by the server and could conflict with real
relation attributes with matching patterns. "expr" and "exprN", N
incremented automatically after the creation of the first one, are used
as default attribute names for index expressions, and that could easily
match what is defined in other relations, causing the dumps to fail if
some of those attributes are renamed at some point. So to avoid any
problems, the new grammar with column numbers gets used.
Reported-by: Ronan Dunklau
Author: Michael Paquier
Reviewed-by: Tom Lane, Adrien Nayrat, Amul Sul
Discussion: https://postgr.es/m/CAARsnT3UQ4V=yDNW468w8RqHfYiY9mpn2r_c5UkBJ97NAApUEw@mail.gmail.com
Backpatch-through: 11, where the new syntax has been introduced.
M src/bin/pg_dump/pg_dump.c
M src/bin/pg_dump/pg_dump.h
M src/bin/pg_dump/t/002_pg_dump.pl
Clarify runtime pruning in EXPLAIN
commit : f760a8b5cc1fa8c9d341faaf2cbda3b94d5a20d9
author : Alvaro Herrera <[email protected]>
date : Mon, 17 Dec 2018 11:44:19 -0300
committer: Alvaro Herrera <[email protected]>
date : Mon, 17 Dec 2018 11:44:19 -0300
Author: Amit Langote
Reviewed-by: David Rowley
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ddl.sgml
Remove extra semicolons.
commit : f88dd4fa43b4edf4fb906e95c55a706d9508021b
author : Amit Kapila <[email protected]>
date : Mon, 17 Dec 2018 14:19:11 +0530
committer: Amit Kapila <[email protected]>
date : Mon, 17 Dec 2018 14:19:11 +0530
Reported-by: David Rowley
Author: David Rowley
Reviewed-by: Amit Kapila
Backpatch-through: 10
Discussion: https://postgr.es/m/CAKJS1f8EneeYyzzvdjahVZ6gbAHFkHbSFB5m_C0Y6TUJs9Dgdg@mail.gmail.com
M src/backend/commands/trigger.c
M src/backend/optimizer/prep/prepunion.c
Fix use-after-free bug when renaming constraints
commit : e83e0988dc62026dbabad76b206bddea3d4f830e
author : Michael Paquier <[email protected]>
date : Mon, 17 Dec 2018 12:43:39 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 17 Dec 2018 12:43:39 +0900
This is an oversight from recent commit b13fd344. While on it, tweak
the previous test with a better name for the renamed primary key.
Detected by buildfarm member prion which forces relation cache release
with -DRELCACHE_FORCE_RELEASE. Back-patch down to 9.4 as the previous
commit.
M src/backend/commands/tablecmds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Make constraint rename issue relcache invalidation on target relation
commit : 25b8094d33ac66773ba1418457cb74eb22b5d50a
author : Michael Paquier <[email protected]>
date : Mon, 17 Dec 2018 10:36:03 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 17 Dec 2018 10:36:03 +0900
When a constraint gets renamed, it may have associated with it a target
relation (for example domain constraints don't have one). Not
invalidating the target relation cache when issuing the renaming can
result in issues with subsequent commands that refer to the old
constraint name using the relation cache, causing various failures. One
pattern spotted was using CREATE TABLE LIKE after a constraint
renaming.
Reported-by: Stuart <[email protected]>
Author: Amit Langote
Reviewed-by: Michael Paquier
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/tablecmds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Make error handling in parallel pg_upgrade less bogus.
commit : b054498c74c3630348b9a35f7f4c6dc90e204643
author : Tom Lane <[email protected]>
date : Sun, 16 Dec 2018 14:51:47 -0500
committer: Tom Lane <[email protected]>
date : Sun, 16 Dec 2018 14:51:47 -0500
reap_child() basically ignored the possibility of either an error in
waitpid() itself or a child process failure on signal. We don't really
need to do more than report and crash hard, but proceeding as though
nothing is wrong is definitely Not Acceptable. The error report for
nonzero child exit status was pretty off-point, as well.
Noted while fooling around with child-process failure detection
logic elsewhere. It's been like this a long time, so back-patch to
all supported branches.
M src/bin/pg_upgrade/parallel.c
Improve detection of child-process SIGPIPE failures.
commit : b1894a6076f36a20338e0c3b0eb73a250ea2e47e
author : Tom Lane <[email protected]>
date : Sun, 16 Dec 2018 14:32:14 -0500
committer: Tom Lane <[email protected]>
date : Sun, 16 Dec 2018 14:32:14 -0500
Commit ffa4cbd62 added logic to detect SIGPIPE failure of a COPY child
process, but it only worked correctly if the SIGPIPE occurred in the
immediate child process. Depending on the shell in use and the
complexity of the shell command string, we might instead get back
an exit code of 128 + SIGPIPE, representing a shell error exit
reporting SIGPIPE in the child process.
We could just hack up ClosePipeToProgram() to add the extra case,
but it seems like this is a fairly general issue deserving a more
general and better-documented solution. I chose to add a couple
of functions in src/common/wait_error.c, which is a natural place
to know about wait-result encodings, that will test for either a
specific child-process signal type or any child-process signal failure.
Then, adjust other places that were doing ad-hoc tests of this type
to use the common functions.
In RestoreArchivedFile, this fixes a race condition affecting whether
the process will report an error or just silently proc_exit(1): before,
that depended on whether the intermediate shell got SIGTERM'd itself
or reported a child process failing on SIGTERM.
Like the previous patch, back-patch to v10; we could go further
but there seems no real need to.
Per report from Erik Rijkers.
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/transam/xlogarchive.c
M src/backend/commands/copy.c
M src/backend/postmaster/pgarch.c
M src/common/wait_error.c
M src/include/port.h
Fix bogus logic for skipping unnecessary partcollation dependencies.
commit : 171cae1579124a400e234f89c1fc80f3caed5f68
author : Tom Lane <[email protected]>
date : Thu, 13 Dec 2018 15:11:09 -0500
committer: Tom Lane <[email protected]>
date : Thu, 13 Dec 2018 15:11:09 -0500
The idea here is to not call recordDependencyOn for the default collation,
since we know that's pinned. But what the code actually did was to record
the partition key's dependency on the opclass twice, instead.
Evidently introduced by sloppy coding in commit 2186b608b. Back-patch
to v10 where that came in.
M src/backend/catalog/heap.c
Prevent GIN deleted pages from being reclaimed too early
commit : dd951dc34a2ecde28cd8d686cd06de1d21f474a0
author : Alexander Korotkov <[email protected]>
date : Thu, 13 Dec 2018 06:12:31 +0300
committer: Alexander Korotkov <[email protected]>
date : Thu, 13 Dec 2018 06:12:31 +0300
When GIN vacuum deletes a posting tree page, it assumes that no concurrent
searchers can access it, thanks to ginStepRight() locking two pages at once.
However, since 9.4 searches can skip parts of posting trees descending from the
root. That leads to the risk that page is deleted and reclaimed before
concurrent search can access it.
This commit prevents the risk of above by waiting for every transaction, which
might wait to reference this page, to finish. Due to binary compatibility
we can't change GinPageOpaqueData to store corresponding transaction id.
Instead we reuse page header pd_prune_xid field, which is unused in index pages.
Discussion: https://postgr.es/m/31a702a.14dd.166c1366ac1.Coremail.chjischj%40163.com
Author: Andrey Borodin, Alexander Korotkov
Reviewed-by: Alexander Korotkov
Backpatch-through: 9.4
M src/backend/access/gin/README
M src/backend/access/gin/ginutil.c
M src/backend/access/gin/ginvacuum.c
M src/backend/access/gin/ginxlog.c
M src/include/access/ginblock.h
M src/include/access/ginxlog.h
Prevent deadlock in ginRedoDeletePage()
commit : 225b5c9c480fa90d4734ce4a8d1a4b46ac5e826e
author : Alexander Korotkov <[email protected]>
date : Thu, 13 Dec 2018 06:12:25 +0300
committer: Alexander Korotkov <[email protected]>
date : Thu, 13 Dec 2018 06:12:25 +0300
On standby ginRedoDeletePage() can work concurrently with read-only queries.
Those queries can traverse posting tree in two ways.
1) Using rightlinks by ginStepRight(), which locks the next page before
unlocking its left sibling.
2) Using downlinks by ginFindLeafPage(), which locks at most one page at time.
Original lock order was: page, parent, left sibling. That lock order can
deadlock with ginStepRight(). In order to prevent deadlock this commit changes
lock order to: left sibling, page, parent. Note, that position of parent in
locking order seems insignificant, because we only lock one page at time while
traversing downlinks.
Reported-by: Chen Huajun
Diagnosed-by: Chen Huajun, Peter Geoghegan, Andrey Borodin
Discussion: https://postgr.es/m/31a702a.14dd.166c1366ac1.Coremail.chjischj%40163.com
Author: Alexander Korotkov
Backpatch-through: 9.4
M src/backend/access/gin/ginxlog.c
Fix deadlock in GIN vacuum introduced by 218f51584d5
commit : 9aa94d8536f81168b6de3744c1fb4a173af1cefe
author : Alexander Korotkov <[email protected]>
date : Thu, 13 Dec 2018 06:12:11 +0300
committer: Alexander Korotkov <[email protected]>
date : Thu, 13 Dec 2018 06:12:11 +0300
Before 218f51584d5 if posting tree page is about to be deleted, then the whole
posting tree is locked by LockBufferForCleanup() on root preventing all the
concurrent inserts. 218f51584d5 reduced locking to the subtree containing
page to be deleted. However, due to concurrent parent split, inserter doesn't
always holds pins on all the pages constituting path from root to the target
leaf page. That could cause a deadlock between GIN vacuum process and GIN
inserter. And we didn't find non-invasive way to fix this.
This commit reverts VACUUM behavior to lock the whole posting tree before
delete any page. However, we keep another useful change by 218f51584d5: the
tree is locked only if there are pages to be deleted.
Reported-by: Chen Huajun
Diagnosed-by: Chen Huajun, Andrey Borodin, Peter Geoghegan
Discussion: https://postgr.es/m/31a702a.14dd.166c1366ac1.Coremail.chjischj%40163.com
Author: Alexander Korotkov, based on ideas from Andrey Borodin and Peter Geoghegan
Reviewed-by: Andrey Borodin
Backpatch-through: 10
M src/backend/access/gin/README
M src/backend/access/gin/ginvacuum.c
Repair bogus EPQ plans generated for postgres_fdw foreign joins.
commit : 7465871879abdc43dad7b5f6dcf1dd4880d53f9e
author : Tom Lane <[email protected]>
date : Wed, 12 Dec 2018 16:08:30 -0500
committer: Tom Lane <[email protected]>
date : Wed, 12 Dec 2018 16:08:30 -0500
postgres_fdw's postgresGetForeignPlan() assumes without checking that the
outer_plan it's given for a join relation must have a NestLoop, MergeJoin,
or HashJoin node at the top. That's been wrong at least since commit
4bbf6edfb (which could cause insertion of a Sort node on top) and it seems
like a pretty unsafe thing to Just Assume even without that.
Through blind good fortune, this doesn't seem to have any worse
consequences today than strange EXPLAIN output, but it's clearly trouble
waiting to happen.
To fix, test the node type explicitly before touching Join-specific
fields, and avoid jamming the new tlist into a node type that can't
do projection. Export a new support function from createplan.c
to avoid building low-level knowledge about the latter into FDWs.
Back-patch to 9.6 where the faulty coding was added. Note that the
associated regression test cases don't show any changes before v11,
apparently because the tests back-patched with 4bbf6edfb don't actually
exercise the problem case before then (there's no top-level Sort
in those plans).
Discussion: https://postgr.es/m/[email protected]
M contrib/postgres_fdw/expected/postgres_fdw.out
M contrib/postgres_fdw/postgres_fdw.c
M src/backend/optimizer/plan/createplan.c
M src/include/optimizer/planmain.h
Repair bogus handling of multi-assignment Params in upper plan levels.
commit : 302d4eee933ec76ef91575d6129558caa64307ca
author : Tom Lane <[email protected]>
date : Wed, 12 Dec 2018 13:49:41 -0500
committer: Tom Lane <[email protected]>
date : Wed, 12 Dec 2018 13:49:41 -0500
Our support for multiple-set-clauses in UPDATE assumes that the Params
referencing a MULTIEXPR_SUBLINK SubPlan will appear before that SubPlan
in the targetlist of the plan node that calculates the updated row.
(Yeah, it's a hack...) In some PG branches it's possible that a Result
node gets inserted between the primary calculation of the update tlist
and the ModifyTable node. setrefs.c did the wrong thing in this case
and left the upper-level Params as Params, causing a crash at runtime.
What it should do is replace them with "outer" Vars referencing the child
plan node's output. That's a result of careless ordering of operations
in fix_upper_expr_mutator, so we can fix it just by reordering the code.
Fix fix_join_expr_mutator similarly for consistency, even though join
nodes could never appear in such a context. (In general, it seems
likely to be a bit cheaper to use Vars than Params in such situations
anyway, so this patch might offer a tiny performance improvement.)
The hazard extends back to 9.5 where the MULTIEXPR_SUBLINK stuff
was introduced, so back-patch that far. However, this may be a live
bug only in 9.6.x and 10.x, as the other branches don't seem to want
to calculate the final tlist below the Result node. (That plan shape
change between branches might be a mini-bug in itself, but I'm not
really interested in digging into the reasons for that right now.
Still, add a regression test memorializing what we expect there,
so we'll notice if it changes again.)
Per bug report from Eduards Bezverhijs.
Discussion: https://postgr.es/m/[email protected]
M src/backend/optimizer/plan/setrefs.c
M src/test/regress/expected/update.out
M src/test/regress/sql/update.sql
Fix test_rls_hooks to assign expression collations properly.
commit : 4e33da5f0af340da40bd51354b87332c551a4bbc
author : Tom Lane <[email protected]>
date : Tue, 11 Dec 2018 11:48:00 -0500
committer: Tom Lane <[email protected]>
date : Tue, 11 Dec 2018 11:48:00 -0500
This module overlooked this necessary fixup step on the results of
transformWhereClause(). It accidentally worked anyway, because the
constructed expression involved type "name" which is not collatable,
but it fell over while I was experimenting with changing "name" to
be collatable.
Back-patch, not because there's any live bug here in back branches,
but because somebody might use this code as a model for some real
application and then not understand why it doesn't work.
M src/test/modules/test_rls_hooks/test_rls_hooks.c
Doc: improve documentation about ALTER LARGE OBJECT requirements.
commit : 9fbe7d974026925dc6f671e72c47fae3b3e49688
author : Tom Lane <[email protected]>
date : Tue, 11 Dec 2018 11:21:36 -0500
committer: Tom Lane <[email protected]>
date : Tue, 11 Dec 2018 11:21:36 -0500
Unlike other ALTER ref pages, this one neglected to mention that
ALTER OWNER requires being a member of the new owning role.
Per bug #15546 from Stefan Kadow.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ref/alter_large_object.sgml
Raise some timeouts to 180s, in test code.
commit : 73822b8c9750c3d1da5232916c573319a80c24e3
author : Noah Misch <[email protected]>
date : Mon, 10 Dec 2018 20:15:42 -0800
committer: Noah Misch <[email protected]>
date : Mon, 10 Dec 2018 20:15:42 -0800
Slow runs of buildfarm members chipmunk, hornet and mandrill saw the
shorter timeouts expire. The 180s timeout in poll_query_until has been
trouble-free since 2a0f89cd717ce6d49cdc47850577823682167e87 introduced
it two years ago, so use 180s more widely. Back-patch to 9.6, where the
first of these timeouts was introduced.
Reviewed by Michael Paquier.
Discussion: https://postgr.es/m/[email protected]
M src/test/isolation/README
M src/test/isolation/isolationtester.c
M src/test/recovery/t/006_logical_decoding.pl
M src/test/recovery/t/010_logical_decoding_timelines.pl
Add stack depth checks to key recursive functions in backend/nodes/*.c.
commit : 62999b93251eefbfcf900a0bb202721b0a422ffd
author : Tom Lane <[email protected]>
date : Mon, 10 Dec 2018 11:12:43 -0500
committer: Tom Lane <[email protected]>
date : Mon, 10 Dec 2018 11:12:43 -0500
Although copyfuncs.c has a check_stack_depth call in its recursion,
equalfuncs.c, outfuncs.c, and readfuncs.c lacked one. This seems
unwise.
Likewise fix planstate_tree_walker(), in branches where that exists.
Discussion: https://postgr.es/m/[email protected]
M src/backend/nodes/equalfuncs.c
M src/backend/nodes/nodeFuncs.c
M src/backend/nodes/outfuncs.c
M src/backend/nodes/readfuncs.c
Make TupleDescInitBuiltinEntry throw error for unsupported types.
commit : a628e0c5b484eed450093258440cf858bcdb0555
author : Tom Lane <[email protected]>
date : Mon, 10 Dec 2018 10:38:49 -0500
committer: Tom Lane <[email protected]>
date : Mon, 10 Dec 2018 10:38:49 -0500
Previously, it would just pass back a partially-uninitialized tupdesc,
which doesn't seem like a safe or useful behavior.
Backpatch to v10 where this code came in.
Discussion: https://postgr.es/m/[email protected]
M src/backend/access/common/tupdesc.c
Fix misapplication of pgstat_count_truncate to wrong relation.
commit : aedd3d4dbd6ecf73a4045e302b68cc498d0e6b58
author : Tom Lane <[email protected]>
date : Fri, 7 Dec 2018 12:12:00 -0500
committer: Tom Lane <[email protected]>
date : Fri, 7 Dec 2018 12:12:00 -0500
The stanza of ExecuteTruncate[Guts] that truncates a target table's toast
relation re-used the loop local variable "rel" to reference the toast rel.
This was safe enough when written, but commit d42358efb added code below
that that supposed "rel" still pointed to the parent table. Therefore,
the stats counter update was applied to the wrong relcache entry (the
toast rel not the user rel); and if we were unlucky and that relcache
entry had been flushed during reindex_relation, very bad things could
ensue.
(I'm surprised that CLOBBER_CACHE_ALWAYS testing hasn't found this.
I'm even more surprised that the problem wasn't detected during the
development of d42358efb; it must not have been tested in any case
with a toast table, as the incorrect stats counts are very obvious.)
To fix, replace use of "rel" in that code branch with a more local
variable. Adjust test cases added by d42358efb so that some of them
use tables with toast tables.
Per bug #15540 from Pan Bian. Back-patch to 9.5 where d42358efb came in.
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/tablecmds.c
M src/test/regress/expected/stats.out
M src/test/regress/sql/stats.sql
Clean up sloppy coding in publicationcmds.c's OpenTableList().
commit : 6bc8193193201652b75a682fa6257ac24b22ed23
author : Tom Lane <[email protected]>
date : Fri, 7 Dec 2018 11:02:39 -0500
committer: Tom Lane <[email protected]>
date : Fri, 7 Dec 2018 11:02:39 -0500
Remove dead code (which would be incorrect if it weren't dead),
per report from Pan Bian. Add a CHECK_FOR_INTERRUPTS in the
inner loop over child relations, because there's little point
in having one in the outer loop if there's not one here too.
Minor stylistic adjustments and comment improvements.
Seems to be aboriginal to this code (cf commit 665d1fad9).
Back-patch to v10 where that came in, not because any of this
is significant, but just to keep the branches looking similar.
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/publicationcmds.c
Doc: make cross-reference to format() function more specific.
commit : 4c6d6acec5f228604d99162dfbc3b3c028dcfdfe
author : Tom Lane <[email protected]>
date : Fri, 7 Dec 2018 10:41:26 -0500
committer: Tom Lane <[email protected]>
date : Fri, 7 Dec 2018 10:41:26 -0500
Jeff Janes
Discussion: https://postgr.es/m/CAMkU=1w7Tn2M9BhK+rt8Shtz1AkU+ty7By8gj5C==z65=U4vyQ@mail.gmail.com
M doc/src/sgml/plpgsql.sgml
Improve our response to invalid format strings, and detect more cases.
commit : d8e1de899c8ec480af6696350957b13a2cc3ff0b
author : Tom Lane <[email protected]>
date : Thu, 6 Dec 2018 15:08:44 -0500
committer: Tom Lane <[email protected]>
date : Thu, 6 Dec 2018 15:08:44 -0500
Places that are testing for *printf failure ought to include the format
string in their error reports, since bad-format-string is one of the
more likely causes of such failure. This both makes it easier to find
and repair the mistake, and provides at least some useful info to the
user who stumbles across such a problem.
Also, tighten snprintf.c to report EINVAL for an invalid flag or
final character in a format %-spec (including the case where the
%-spec is missing a final character altogether). This seems like
better project policy, and it also allows removing an instruction
or two from the hot code path.
Back-patch the error reporting change in pvsnprintf, since it should be
harmless and may be helpful; but not the snprintf.c change.
Per discussion of bug #15511 from Ertuğrul Kahveci, which reported an
invalid translated format string. These changes don't fix that error,
but they should improve matters next time we make such a mistake.
Discussion: https://postgr.es/m/[email protected]
M src/common/psprintf.c
Improve planner stats documentation
commit : aa175f61e0fcef16af57f82968a59ed5324146ca
author : Stephen Frost <[email protected]>
date : Thu, 6 Dec 2018 11:39:03 -0500
committer: Stephen Frost <[email protected]>
date : Thu, 6 Dec 2018 11:39:03 -0500
It was pointed out that in the planner stats documentation under
Extended Statistics, one of the sentences was a bit awkward. Improve
that by rewording it slightly.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/perform.sgml
Don't mark partitioned indexes invalid unnecessarily
commit : 37798a8e83db978c7d92f2491935c6ba96b95fbc
author : Alvaro Herrera <[email protected]>
date : Wed, 5 Dec 2018 13:31:55 -0300
committer: Alvaro Herrera <[email protected]>
date : Wed, 5 Dec 2018 13:31:55 -0300
When an indexes is created on a partitioned table using ONLY (don't
recurse to partitions), it gets marked invalid until index partitions
are attached for each table partition. But there's no reason to do this
if there are no partitions ... and moreover, there's no way to get the
index to become valid afterwards, because all partitions that get
created/attached get their own index partition already attached to the
parent index, so there's no chance to do ALTER INDEX ... ATTACH PARTITION
that would make the parent index valid.
Fix by not marking the index as invalid to begin with.
This is very similar to 9139aa19423b, but the pg_dump aspect does not
appear to be relevant until we add FKs that can point to PKs on
partitioned tables. (I tried to cause the pg_upgrade test to break by
leaving some of these bogus tables around, but wasn't able to.)
Making this change means that an index that was supposed to be invalid
in the insert_conflict regression test is no longer invalid; reorder the
DDL so that the test continues to verify the behavior we want it to.
Author: Álvaro Herrera
Reviewed-by: Amit Langote
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/indexcmds.c
M src/test/regress/expected/insert_conflict.out
M src/test/regress/sql/insert_conflict.sql
Fix invalid value of synchronous_commit in description of flush_lag
commit : 367f362b2d902de1c8f265639980ae001a4307e8
author : Michael Paquier <[email protected]>
date : Wed, 5 Dec 2018 10:02:55 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 5 Dec 2018 10:02:55 +0900
"remote_flush" has never been a valid user-facing value, but "on" is.
Author: Maksim Milyutin
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/monitoring.sgml
Fix various checksum check problems for pg_verify_checksums and base backups
commit : 19516afdf167aeaf9e95edf7c5a105bb16f8914c
author : Michael Paquier <[email protected]>
date : Fri, 30 Nov 2018 10:34:56 +0900
committer: Michael Paquier <[email protected]>
date : Fri, 30 Nov 2018 10:34:56 +0900
Three issues are fixed in this patch:
- Base backups forgot to ignore files specific to EXEC_BACKEND, leading
to spurious warnings when checksums are enabled, per analysis from me.
- pg_verify_checksums forgot about files specific to EXEC_BACKEND,
leading to failures of the tool on any such build, particularly Windows.
This error was originally found by newly-introduced TAP tests in various
buildfarm members using EXEC_BACKEND.
- pg_verify_checksums forgot to count for temporary files and temporary
paths, which could be valid relation files, without checksums, per
report from Andres Freund. More tests are added to cover this case.
A new test case which emulates corruption for a file in a different
tablespace is added, coming from from Michael Banck, while I have coded
the main code and refactored the test code.
Author: Michael Banck, Michael Paquier
Reviewed-by: Stephen Frost, David Steele
Discussion: https://postgr.es/m/[email protected]
M src/backend/replication/basebackup.c
M src/bin/pg_verify_checksums/pg_verify_checksums.c
Switch pg_verify_checksums back to a blacklist
commit : 85036308dc5871b1d41e4292fa089d3809963252
author : Michael Paquier <[email protected]>
date : Fri, 30 Nov 2018 10:15:06 +0900
committer: Michael Paquier <[email protected]>
date : Fri, 30 Nov 2018 10:15:06 +0900
This basically reverts commit d55241af705667d4503638e3f77d3689fd6be31,
leaving around a portion of the regression tests still adapted with
empty relation files, and corrupted cases. This is also proving to be
failing to check properly relation files located in a non-default
tablespace path.
Per discussion with various folks, including Stephen Frost, David
Steele, Andres Freund, Michael Banck and myself.
Reported-by: Michael Banck
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 11
M src/bin/pg_verify_checksums/pg_verify_checksums.c
Document handling of invalid/ambiguous timestamp input near DST boundaries.
commit : 53a5ceb2b68bc90a2ebd40e489d79f6e02441378
author : Tom Lane <[email protected]>
date : Thu, 29 Nov 2018 18:28:10 -0500
committer: Tom Lane <[email protected]>
date : Thu, 29 Nov 2018 18:28:10 -0500
The source code comments documented this, but the user-facing docs, not
so much. Add a section to Appendix B that discusses it.
In passing, improve a couple other things in Appendix B --- notably,
a long-obsolete claim that time zone abbreviations are looked up in
a fixed table.
Per bug #15527 from Michael Davidson.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/datetime.sgml
Ensure static libraries have correct mod time even if ranlib messes it up.
commit : 0ff56de46eb0a045417c5c22a5a07c4d6ea9ff78
author : Tom Lane <[email protected]>
date : Thu, 29 Nov 2018 15:53:44 -0500
committer: Tom Lane <[email protected]>
date : Thu, 29 Nov 2018 15:53:44 -0500
In at least Apple's version of ranlib, the output file is updated to have
a mod time equal to the max of the timestamps of its components, and that
data only has seconds precision. On a filesystem with sub-second file
timestamp precision --- say, APFS --- this can result in the finished
static library appearing older than its input files, which causes useless
rebuilds and possible outright failures in parallel makes.
We've only seen this reported in the field from people using Apple's
ranlib with a non-Apple make, because Apple's make doesn't know about
sub-second timestamps either so it doesn't decide rebuilds are needed.
But Apple's ranlib presumably shares code with at least some BSDen,
so it's not that unlikely that the same problem could arise elsewhere.
To fix, just "touch" the output file after ranlib finishes.
We seem to need this in only one place. There are other calls of
ranlib in our makefiles, but they are working on intermediate files
whose timestamps are not actually important, or else on an installed
static library for which sub-second timestamp precision is unlikely
to matter either. (Also, so far as I can tell, Apple's ranlib doesn't
mess up the file timestamp in the latter usage anyhow.)
In passing, change "ranlib" to "$(RANLIB)" in one place that was
bypassing the make macro for no good reason.
Per bug #15525 from Jack Kelly (via Alyssa Ross).
Back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/Makefile.shlib
Fix minor typo in dsa.c.
commit : f7001b00a08f37bac306a6ae2028afb3dd2c5084
author : Thomas Munro <[email protected]>
date : Thu, 29 Nov 2018 14:14:26 +1300
committer: Thomas Munro <[email protected]>
date : Thu, 29 Nov 2018 14:14:26 +1300
Author: Takeshi Ideriha
Discussion: https://postgr.es/m/4E72940DA2BF16479384A86D54D0988A6F3BF22D%40G01JPEXMBKW04
M src/backend/utils/mmgr/dsa.c
Fix handling of synchronous replication for stopping WAL senders
commit : bad41764a443605bef9bb3d1c3614e1b3770005d
author : Michael Paquier <[email protected]>
date : Thu, 29 Nov 2018 09:12:40 +0900
committer: Michael Paquier <[email protected]>
date : Thu, 29 Nov 2018 09:12:40 +0900
This fixes an oversight from c6c3334 which forgot that if a subset of
WAL senders are stopping and in a sync state, other WAL senders could
still be waiting for a WAL position to be synced while committing a
transaction. However the subset of stopping senders would not release
waiters, potentially breaking synchronous replication guarantees. This
commit makes sure that even WAL senders stopping are able to release
waiters and are tracked properly.
On 9.4, this can also trigger an assertion failure when setting for
example max_wal_senders to 1 where a WAL sender is not able to find
itself as in synchronous state when the instance stops.
Reported-by: Paul Guo
Author: Paul Guo, Michael Paquier
Discussion: https://postgr.es/m/CAEET0ZEv8VFqT3C-cQm6byOB4r4VYWcef1J21dOX-gcVhCSpmA@mail.gmail.com
Backpatch-through: 9.4
M src/backend/replication/syncrep.c
Have BufFileSize() ereport() on FileSize() failure.
commit : 95c45718126fe081e9236335a85d15ad24adc107
author : Peter Geoghegan <[email protected]>
date : Wed, 28 Nov 2018 14:42:52 -0800
committer: Peter Geoghegan <[email protected]>
date : Wed, 28 Nov 2018 14:42:52 -0800
Move the responsibility for checking for and reporting a failure from
the only current BufFileSize() caller, logtape.c, to BufFileSize()
itself. Code within buffile.c is generally responsible for interfacing
with fd.c to report irrecoverable failures. This seems like a
convention that's worth sticking to.
Reorganizing things this way makes it easy to make the error message
raised in the event of BufFileSize() failure descriptive of the
underlying problem. We're now clear on the distinction between
temporary file name and BufFile name, and can show errno, confident that
its value actually relates to the error being reported. In passing, an
existing, similar buffile.c ereport() + errcode_for_file_access() site
is changed to follow the same conventions.
The API of the function BufFileSize() is changed by this commit, despite
already being in a stable release (Postgres 11). This seems acceptable,
since the BufFileSize() ABI was changed by commit aa551830421, which
hasn't made it into a point release yet. Besides, it's difficult to
imagine a third party BufFileSize() caller not just raising an error
anyway, since BufFile state should be considered corrupt when
BufFileSize() fails.
Per complaint from Tom Lane.
Discussion: https://postgr.es/m/[email protected]
Backpatch: 11-, where shared BufFiles were introduced.
M src/backend/storage/file/buffile.c
M src/backend/utils/sort/logtape.c
C comment: remove extra '*'
commit : 48cf9184ce9574363b310eaf65c7c939a5d40e76
author : Bruce Momjian <[email protected]>
date : Wed, 28 Nov 2018 07:34:10 -0500
committer: Bruce Momjian <[email protected]>
date : Wed, 28 Nov 2018 07:34:10 -0500
Reported-by: Etsuro Fujita
Discussion: https://postgr.es/m/[email protected]
Author: Etsuro Fujita
Backpatch-through: 10
M contrib/postgres_fdw/postgres_fdw.c
Don't set PAM_RHOST for Unix sockets.
commit : 0640d9517e7e6804851a5f0d2520d51fc6faf014
author : Thomas Munro <[email protected]>
date : Wed, 28 Nov 2018 14:00:57 +1300
committer: Thomas Munro <[email protected]>
date : Wed, 28 Nov 2018 14:00:57 +1300
Since commit 2f1d2b7a we have set PAM_RHOST to "[local]" for Unix
sockets. This caused Linux PAM's libaudit integration to make DNS
requests for that name. It's not exactly clear what value PAM_RHOST
should have in that case, but it seems clear that we shouldn't set it
to an unresolvable name, so don't do that.
Back-patch to 9.6. Bug #15520.
Author: Thomas Munro
Reviewed-by: Peter Eisentraut
Reported-by: Albert Schabhuetl
Discussion: https://postgr.es/m/15520-4c266f986998e1c5%40postgresql.org
M src/backend/libpq/auth.c
Do not decode TOAST data for table rewrites
commit : f8397c955e54d7093a81b2a84ba44898c6566203
author : Tomas Vondra <[email protected]>
date : Wed, 28 Nov 2018 01:11:15 +0100
committer: Tomas Vondra <[email protected]>
date : Wed, 28 Nov 2018 01:11:15 +0100
During table rewrites (VACUUM FULL and CLUSTER), the main heap is logged
using XLOG / FPI records, and thus (correctly) ignored in decoding.
But the associated TOAST table is WAL-logged as plain INSERT records,
and so was logically decoded and passed to reorder buffer.
That has severe consequences with TOAST tables of non-trivial size.
Firstly, reorder buffer has to keep all those changes, possibly spilling
them to a file, incurring I/O costs and disk space.
Secondly, ReoderBufferCommit() was stashing all those TOAST chunks into
a hash table, which got discarded only after processing the row from the
main heap. But as the main heap is not decoded for rewrites, this never
happened, so all the TOAST data accumulated in memory, resulting either
in excessive memory consumption or OOM.
The fix is simple, as commit e9edc1ba already introduced infrastructure
(namely HEAP_INSERT_NO_LOGICAL flag) to skip logical decoding of TOAST
tables, but it only applied it to system tables. So simply use it for
all TOAST data in raw_heap_insert().
That would however solve only the memory consumption issue - the TOAST
changes would still be decoded and added to the reorder buffer, and
spilled to disk (although without TOAST tuple data, so much smaller).
But we can solve that by tweaking DecodeInsert() to just ignore such
INSERT records altogether, using XLH_INSERT_CONTAINS_NEW_TUPLE flag,
instead of skipping them later in ReorderBufferCommit().
Review: Masahiko Sawada
Discussion: https://www.postgresql.org/message-id/flat/1a17c643-e9af-3dba-486b-fbe31bc1823a%402ndquadrant.com
Backpatch: 9.4-, where logical decoding was introduced
M src/backend/access/heap/rewriteheap.c
M src/backend/replication/logical/decode.c
M src/backend/replication/logical/reorderbuffer.c
Fix jit compilation bug on wide tables.
commit : aee085bc018ffb961bf0a2c3ac72a45bb3aa33a9
author : Andres Freund <[email protected]>
date : Tue, 27 Nov 2018 10:07:43 -0800
committer: Andres Freund <[email protected]>
date : Tue, 27 Nov 2018 10:07:43 -0800
The function generated to perform JIT compiled tuple deforming failed
when HeapTupleHeader's t_hoff was bigger than a signed int8. I'd
failed to realize that LLVM's getelementptr would treat an int8 index
argument as signed, rather than unsigned. That means that a hoff
larger than 127 would result in a negative offset being applied. Fix
that by widening the index to 32bit.
Add a testcase with a wide table. Don't drop it, as it seems useful to
verify other tools deal properly with wide tables.
Thanks to Justin Pryzby for both reporting a bug and then reducing it
to a reproducible testcase!
Reported-By: Justin Pryzby
Author: Andres Freund
Discussion: https://postgr.es/m/[email protected]
Backpatch: 11, just as jit compilation was
M src/backend/jit/llvm/llvmjit_deform.c
M src/test/regress/expected/create_table.out
M src/test/regress/expected/sanity_check.out
M src/test/regress/sql/create_table.sql
Fix ac218aa4f6 to work on versions before 9.5.
commit : 5ef8f08b541da5df1ac00a3c880578a8e3bf447c
author : Andres Freund <[email protected]>
date : Mon, 26 Nov 2018 23:26:05 -0800
committer: Andres Freund <[email protected]>
date : Mon, 26 Nov 2018 23:26:05 -0800
Unfortunately ac218aa4f6 missed the fact that a reference to
'pg_catalog.regnamespace'::regclass wouldn't work before that type is
known. Fix that, by replacing the regtype usage with a join to
pg_type.
Reported-By: Tom Lane
Author: Andres Freund
Discussion: https://postgr.es/m/[email protected]
Backpatch: 9.5-, like ac218aa4f6
M src/bin/pg_upgrade/check.c
Update pg_upgrade test for reg* to include regrole and regnamespace.
commit : 203a909fd29656d65a451c791e326ff92a09d893
author : Andres Freund <[email protected]>
date : Mon, 26 Nov 2018 17:00:43 -0800
committer: Andres Freund <[email protected]>
date : Mon, 26 Nov 2018 17:00:43 -0800
When the regrole (0c90f6769) and regnamespace (cb9fa802b) types were
added in 9.5, pg_upgrade's check for reg* types wasn't updated. While
regrole currently is safe, regnamespace is not.
It seems unlikely that anybody uses regnamespace inside catalog tables
across a pg_upgrade, but the tests should be correct nevertheless.
While at it, reorder the types checked in the query to be
alphabetical. Otherwise it's annoying to compare existing and tested
for types.
Author: Andres Freund
Discussion: https://postgr.es/m/[email protected]
Backpatch: 9.5-, as regrole/regnamespace
M src/bin/pg_upgrade/check.c
doc: fix wording for plpgsql, add "and"
commit : ad6dfc6ab3e48126edd38b149134b7311124648b
author : Bruce Momjian <[email protected]>
date : Mon, 26 Nov 2018 19:41:19 -0500
committer: Bruce Momjian <[email protected]>
date : Mon, 26 Nov 2018 19:41:19 -0500
Reported-by: Anthony Greene
Discussion: https://postgr.es/m/CAPRNmnsSZ4QL75FUjcS8ND_oV+WjgyPbZ4ch2RUwmW6PWzF38w@mail.gmail.com
Backpatch-through: 9.4
M doc/src/sgml/plpgsql.sgml
Fix translation of special characters in psql's LaTeX output modes.
commit : b352cf7a80e0841017ca198f27f9da49d7256739
author : Tom Lane <[email protected]>
date : Mon, 26 Nov 2018 17:32:51 -0500
committer: Tom Lane <[email protected]>
date : Mon, 26 Nov 2018 17:32:51 -0500
latex_escaped_print() mistranslated \ and failed to provide any translation
for # ^ and ~, all of which would typically lead to LaTeX document syntax
errors. In addition it didn't translate < > and |, which would typically
render as unexpected characters.
To some extent this represents shortcomings in ancient versions of LaTeX,
which if memory serves had no easy way to render these control characters
as ASCII text. But that's been fixed for, um, decades. In any case there
is no value in emitting guaranteed-to-fail output for these characters.
Noted while fooling with test cases added by commit 9a98984f4. Back-patch
the code change to all supported versions.
M src/fe_utils/print.c
Fix sample output for hash_metapage_info query
commit : 6a13deffd4983bcc0b21f4df0a5d86cd94b6e05a
author : Alvaro Herrera <[email protected]>
date : Mon, 26 Nov 2018 16:58:02 -0300
committer: Alvaro Herrera <[email protected]>
date : Mon, 26 Nov 2018 16:58:02 -0300
One output column was duplicated. Couldn't resist fixing the version
number while at it.
Reported-by: Gianni Ciolli
M doc/src/sgml/pageinspect.sgml
Revert "Fix typo in documentation of toast storage"
commit : 84ac4d7d59adcd6d159244d769a414741cbce62f
author : Michael Paquier <[email protected]>
date : Mon, 26 Nov 2018 16:43:19 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 26 Nov 2018 16:43:19 +0900
This reverts commit 058ef3a, per complains from Magnus Hagander and Vik
Fearing.
M doc/src/sgml/storage.sgml
Fix typo in documentation of toast storage
commit : b81bcd619105a6d520b8cc21cf2f0d6717332e03
author : Michael Paquier <[email protected]>
date : Mon, 26 Nov 2018 15:49:23 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 26 Nov 2018 15:49:23 +0900
Author: Nawaz Ahmed
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/storage.sgml
Fix hstore hash function for empty hstores upgraded from 8.4.
commit : 02e669c0f7ddbdc4f1ca74bfa5ccfcfca782f144
author : Andrew Gierth <[email protected]>
date : Sat, 24 Nov 2018 09:59:49 +0000
committer: Andrew Gierth <[email protected]>
date : Sat, 24 Nov 2018 09:59:49 +0000
Hstore data generated on pg 8.4 and pg_upgraded to current versions
remains in its original on-disk format unless modified. The same goes
for values generated by the addon hstore-new module on pre-9.0
versions. (The hstoreUpgrade function converts old values on the fly
when read in, but the on-disk value is not modified by this.)
Since old-format empty hstores (and hstore-new hstores) have
representations compatible with the new format, hstoreUpgrade thought
it could get away without modifying such values; but this breaks
hstore_hash (and the new hstore_hash_extended) which assumes
bit-perfect matching between semantically identical hstore values.
Only one bit actually differs (the "new version" flag in the count
field) but that of course is enough to break the hash.
Fix by making hstoreUpgrade unconditionally convert all old values to
new format.
Backpatch all the way, even though this changes a hash value in some
cases, because in those cases the hash value is already failing - for
example, a hash join between old- and new-format empty hstores will be
failing to match, or a hash index on an hstore column containing an
old-format empty value will be failing to find the value since it will
be searching for a hash derived from a new-format datum. (There are no
known field reports of this happening, probably because hashing of
hstores has only been useful in limited circumstances and there
probably isn't much upgraded data being used this way.)
Per concerns arising from discussion of commit eb6f29141be. Original
bug is my fault.
Discussion: https://postgr.es/m/60b1fd3b-7332-40f0-7e7f-f2f04f777747%402ndquadrant.com
M contrib/hstore/hstore_compat.c
Update additional float4/8 expected-output files.
commit : 3645d31934f4b631824ffe66314d2e9f0b0377c2
author : Tom Lane <[email protected]>
date : Sat, 24 Nov 2018 13:53:12 -0500
committer: Tom Lane <[email protected]>
date : Sat, 24 Nov 2018 13:53:12 -0500
I forgot that the back branches have more variant files than HEAD :-(.
Per buildfarm.
Discussion: https://postgr.es/m/[email protected]
M src/test/regress/expected/float4-exp-three-digits.out
M src/test/regress/expected/float8-exp-three-digits-win32.out
M src/test/regress/expected/float8-small-is-zero_1.out
Fix float-to-integer coercions to handle edge cases correctly.
commit : e473e1f2b8f1b64cae0786bbec66d8fb27efb9b1
author : Tom Lane <[email protected]>
date : Sat, 24 Nov 2018 12:45:49 -0500
committer: Tom Lane <[email protected]>
date : Sat, 24 Nov 2018 12:45:49 -0500
ftoi4 and its sibling coercion functions did their overflow checks in
a way that looked superficially plausible, but actually depended on an
assumption that the MIN and MAX comparison constants can be represented
exactly in the float4 or float8 domain. That fails in ftoi4, ftoi8,
and dtoi8, resulting in a possibility that values near the MAX limit will
be wrongly converted (to negative values) when they need to be rejected.
Also, because we compared before rounding off the fractional part,
the other three functions threw errors for values that really ought
to get rounded to the min or max integer value.
Fix by doing rint() first (requiring an assumption that it handles
NaN and Inf correctly; but dtoi8 and ftoi8 were assuming that already),
and by comparing to values that should coerce to float exactly, namely
INTxx_MIN and -INTxx_MIN. Also remove some random cosmetic discrepancies
between these six functions.
This back-patches commits cbdb8b4c0 and 452b637d4. In the 9.4 branch,
also back-patch the portion of 62e2a8dc2 that added PG_INTnn_MIN and
related constants to c.h, so that these functions can rely on them.
Per bug #15519 from Victor Petrovykh.
Patch by me; thanks to Andrew Gierth for analysis and discussion.
Discussion: https://postgr.es/m/[email protected]
M src/backend/utils/adt/float.c
M src/backend/utils/adt/int8.c
M src/test/regress/expected/float4.out
M src/test/regress/expected/float8-small-is-zero.out
M src/test/regress/expected/float8.out
M src/test/regress/sql/float4.sql
M src/test/regress/sql/float8.sql
Avoid crashes in contrib/intarray gist__int_ops (bug #15518)
commit : 2e497ed235528314b92a8c6a2cfb4aceb5ba1500
author : Andrew Gierth <[email protected]>
date : Fri, 23 Nov 2018 23:56:39 +0000
committer: Andrew Gierth <[email protected]>
date : Fri, 23 Nov 2018 23:56:39 +0000
1. Integer overflow in internal_size could result in memory corruption
in decompression since a zero-length array would be allocated and then
written to. This leads to crashes or corruption when traversing an
index which has been populated with sufficiently sparse values. Fix by
using int64 for computations and checking for overflow.
2. Integer overflow in g_int_compress could cause pessimal merge
choices, resulting in unnecessarily large ranges (which would in turn
trigger issue 1 above). Fix by using int64 again.
3. Even without overflow, array sizes could become large enough to
cause unexplained memory allocation errors. Fix by capping the sizes
to a safe limit and report actual errors pointing at gist__intbig_ops
as needed.
4. Large inputs to the compression function always consist of large
runs of consecutive integers, and the compression loop was processing
these one at a time in an O(N^2) manner with a lot of overhead. The
expected runtime of this function could easily exceed 6 months for a
single call as a result. Fix by performing a linear-time first pass,
which reduces the worst case to something on the order of seconds.
Backpatch all the way, since this has been wrong forever.
Per bug #15518 from report from irc user "dymk", analysis and patch by
me.
Discussion: https://postgr.es/m/[email protected]
M contrib/intarray/_int_gist.c
M contrib/intarray/_int_tool.c
Don't allow partitioned indexes in pg_global tablespace
commit : a5586a0e0b6b6cf58f77fe0f3e506646444e6d51
author : Alvaro Herrera <[email protected]>
date : Fri, 23 Nov 2018 08:44:15 -0300
committer: Alvaro Herrera <[email protected]>
date : Fri, 23 Nov 2018 08:44:15 -0300
Missing in dfa608141982.
Author: David Rowley
Discussion: https://postgr.es/m/CAKJS1f-M3NMTCpv=vDfkoqHbMPFf=3-Z1ud=+1DHH00tC+zLaQ@mail.gmail.com
M src/backend/commands/tablecmds.c
M src/test/regress/input/tablespace.source
M src/test/regress/output/tablespace.source
doc: Fix typo
commit : efcb06f1f593d2db0e953df6cc5b597057bc1716
author : Peter Eisentraut <[email protected]>
date : Fri, 23 Nov 2018 11:41:27 +0100
committer: Peter Eisentraut <[email protected]>
date : Fri, 23 Nov 2018 11:41:27 +0100
M doc/src/sgml/protocol.sgml
Clarify documentation about PASSWORD in CREATE/ALTER ROLE
commit : 3dab288f492d38d60a2cf02ba85c05df6e329ab1
author : Michael Paquier <[email protected]>
date : Fri, 23 Nov 2018 09:11:12 +0900
committer: Michael Paquier <[email protected]>
date : Fri, 23 Nov 2018 09:11:12 +0900
The documentation of CREATE/ALTER ROLE has been missing two things
related to PASSWORD:
- The password value provided needs to be quoted, some places of the
documentation marked the field with quotes, but not others, which led to
confusion.
- PASSWORD NULL was not provided consistently, with ENCRYPTED being not
compatible with it.
Reported-by: Steven Winfield
Author: Michael Paquier
Reviewed-by: David G. Johnston
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ref/alter_role.sgml
M doc/src/sgml/ref/alter_user.sgml
M doc/src/sgml/ref/create_role.sgml
M doc/src/sgml/ref/create_user.sgml
Fix another crash in json{b}_populate_recordset and json{b}_to_recordset.
commit : 595220a3a3a89e5648b7b6be726502efdc9ec806
author : Tom Lane <[email protected]>
date : Thu, 22 Nov 2018 15:14:01 -0500
committer: Tom Lane <[email protected]>
date : Thu, 22 Nov 2018 15:14:01 -0500
populate_recordset_worker() failed to consider the possibility that the
supplied JSON data contains no rows, so that update_cached_tupdesc never
got called. This led to a null-pointer dereference since commit 9a5e8ed28;
before that it led to a bogus "set-valued function called in context that
cannot accept a set" error. Fix by forcing the update to happen.
Per bug #15514. Back-patch to v11 as 9a5e8ed28 was. (If we were excited
about the bogus error, we could perhaps go back further, but it'd take more
work to figure out how to fix it in older branches. Given the lack of
field complaints about that aspect, I'm not excited.)
Discussion: https://postgr.es/m/[email protected]
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: rework introductory documentation about covering indexes.
commit : 2c0791376aeda0868a646d35d95f2be42ec97170
author : Tom Lane <[email protected]>
date : Thu, 22 Nov 2018 13:24:57 -0500
committer: Tom Lane <[email protected]>
date : Thu, 22 Nov 2018 13:24:57 -0500
Documenting INCLUDE in the section about unique indexes is confusing,
as complained of by Emilio Platzer. Furthermore, it entirely failed
to explain why you might want to use the feature. The section about
index-only scans is really the right place; it already talked about
making such things the hard way. Rewrite that text to describe INCLUDE
as the normal way to make a covering index.
Also, move that section up a couple of places, as it now seems more
important than some of the stuff we had before it. It still has to
be after expression and partial indexes, since otherwise some of it
would involve forward references.
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/indices.sgml
doc: adjust time zone names text, v2
commit : dbd9bfd7183349e227d5ed7ade18083c44050fc1
author : Bruce Momjian <[email protected]>
date : Wed, 21 Nov 2018 17:20:15 -0500
committer: Bruce Momjian <[email protected]>
date : Wed, 21 Nov 2018 17:20:15 -0500
Removed one too many words. Fix for
7906de847f229f391b9e6b5892b4b4a89f29edb4.
Reported-by: Thomas Munro
Backpatch-through: 9.4
M doc/src/sgml/datatype.sgml
doc: adjust time zone names text
commit : 2ca4e559de293567c49543b8fad9e79bee3fa6a0
author : Bruce Momjian <[email protected]>
date : Wed, 21 Nov 2018 16:55:40 -0500
committer: Bruce Momjian <[email protected]>
date : Wed, 21 Nov 2018 16:55:40 -0500
Reported-by: Kevin <[email protected]>
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4
M doc/src/sgml/datatype.sgml
doc: Clarify CREATE TYPE ENUM documentation
commit : dc6b125316c8129c85e3fc0f5df872de6c94229f
author : Peter Eisentraut <[email protected]>
date : Tue, 13 Nov 2018 10:42:43 +0100
committer: Peter Eisentraut <[email protected]>
date : Tue, 13 Nov 2018 10:42:43 +0100
The documentation claimed that an enum type requires "one or more"
labels, but since 1fd9883ff49, zero labels are also allowed.
Reported-by: Lukas Eder <[email protected]>
Bug: #15356
M doc/src/sgml/ref/create_type.sgml
Add needed #include.
commit : e2631255e48faff5541259eb775afed0ee96e856
author : Tom Lane <[email protected]>
date : Mon, 19 Nov 2018 17:28:04 -0500
committer: Tom Lane <[email protected]>
date : Mon, 19 Nov 2018 17:28:04 -0500
Per POSIX, WIFSIGNALED and related macros are provided by <sys/wait.h>.
Apparently on Linux they're also pulled in by some other inclusions,
but BSD-ish systems are pickier. Fixes portability issue in ffa4cbd62.
Per buildfarm.
M src/backend/commands/copy.c
Handle EPIPE more sanely when we close a pipe reading from a program.
commit : 8dc49a8934de023c08890035d96916994bd9b297
author : Tom Lane <[email protected]>
date : Mon, 19 Nov 2018 17:02:25 -0500
committer: Tom Lane <[email protected]>
date : Mon, 19 Nov 2018 17:02:25 -0500
Previously, any program launched by COPY TO/FROM PROGRAM inherited the
server's setting of SIGPIPE handling, i.e. SIG_IGN. Hence, if we were
doing COPY FROM PROGRAM and closed the pipe early, the child process
would see EPIPE on its output file and typically would treat that as
a fatal error, in turn causing the COPY to report error. Similarly,
one could get a failure report from a query that didn't read all of
the output from a contrib/file_fdw foreign table that uses file_fdw's
PROGRAM option.
To fix, ensure that child programs inherit SIG_DFL not SIG_IGN processing
of SIGPIPE. This seems like an all-around better situation since if
the called program wants some non-default treatment of SIGPIPE, it would
expect to have to set that up for itself. Then in COPY, if it's COPY
FROM PROGRAM and we stop reading short of detecting EOF, treat a SIGPIPE
exit from the called program as a non-error condition. This still allows
us to report an error for any case where the called program gets SIGPIPE
on some other file descriptor.
As coded, we won't report a SIGPIPE if we stop reading as a result of
seeing an in-band EOF marker (e.g. COPY BINARY EOF marker). It's
somewhat debatable whether we should complain if the called program
continues to transmit data after an EOF marker. However, it seems like
we should avoid throwing error in any questionable cases, especially in a
back-patched fix, and anyway it would take additional code to make such
an error get reported consistently.
Back-patch to v10. We could go further back, since COPY FROM PROGRAM
has been around awhile, but AFAICS the only way to reach this situation
using core or contrib is via file_fdw, which has only supported PROGRAM
sources since v10. The COPY statement per se has no feature whereby
it'd stop reading without having hit EOF or an error already. Therefore,
I don't see any upside to back-patching further that'd outweigh the
risk of complaints about behavioral change.
Per bug #15449 from Eric Cyr.
Patch by me, review by Etsuro Fujita and Kyotaro Horiguchi
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/copy.c
M src/backend/storage/file/fd.c
Postpone LLVM-related uses of AC_CHECK_DECLS.
commit : 923f9c2def111e65a83f65d7caf75efb772314fc
author : Tom Lane <[email protected]>
date : Mon, 19 Nov 2018 12:43:05 -0500
committer: Tom Lane <[email protected]>
date : Mon, 19 Nov 2018 12:43:05 -0500
Calling AC_CHECK_DECLS before we've finished setting up the compiler's
CFLAGS seems like a pretty risky proposition, especially now that the
first use of that macro will result in a test to see whether the compiler
gives warning or error for undeclared built-in functions. That answer
could very easily get changed later than where PGAC_LLVM_SUPPORT is
called; furthermore, it's hardly unlikely that flags such as -D_GNU_SOURCE
could change visibility of declarations. Hence, be a little less cavalier
about where to do LLVM-related tests. This results in v11 and HEAD doing
the warning-or-error check at the same place in the script as older
branches are doing it, which seems like a good thing.
Per further thought about commits 0b59b0e8b and 16fbac39f.
M config/llvm.m4
M configure
M configure.in
Fix configure's AC_CHECK_DECLS tests to work correctly with clang.
commit : dcd6200165ca583cc1b0d436774cf4c3cf7e642d
author : Tom Lane <[email protected]>
date : Mon, 19 Nov 2018 12:01:47 -0500
committer: Tom Lane <[email protected]>
date : Mon, 19 Nov 2018 12:01:47 -0500
The test case that Autoconf uses to discover whether a function has
been declared doesn't work reliably with clang, because clang reports
a warning not an error if the name is a known built-in function.
On some platforms, this results in a lot of compile-time warnings about
strlcpy and related functions not having been declared.
There is a fix for this (by Noah Misch) in the upstream Autoconf sources,
but since they've not made a release in years and show no indication of
doing so anytime soon, let's just absorb their fix directly. We can
revert this when and if we update to a newer Autoconf release.
Back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M aclocal.m4
A config/check_decls.m4
M configure
M configure.in
Disallow COPY FREEZE on partitioned tables
commit : a4db7fe0f71463eb7256d3c42b7a582d3943d604
author : Alvaro Herrera <[email protected]>
date : Mon, 19 Nov 2018 11:16:28 -0300
committer: Alvaro Herrera <[email protected]>
date : Mon, 19 Nov 2018 11:16:28 -0300
This didn't actually work: COPY would fail to flush the right files, and
instead would try to flush a non-existing file, causing the whole
transaction to fail.
Cope by raising an error as soon as the command is sent instead, to
avoid a nasty later surprise. Of course, it would be much better to
make it work, but we don't have a patch for that yet, and we don't know
if we'll want to backpatch one when we do.
Reported-by: Tomas Vondra
Author: David Rowley
Reviewed-by: Amit Langote, Steve Singer, Tomas Vondra
M doc/src/sgml/perform.sgml
M doc/src/sgml/ref/copy.sgml
M src/backend/commands/copy.c
M src/test/regress/input/copy.source
M src/test/regress/output/copy.source
PANIC on fsync() failure.
commit : 6534d544cd77e14a93f5c779fa8addee8d916a66
author : Thomas Munro <[email protected]>
date : Mon, 19 Nov 2018 13:37:59 +1300
committer: Thomas Munro <[email protected]>
date : Mon, 19 Nov 2018 13:37:59 +1300
On some operating systems, it doesn't make sense to retry fsync(),
because dirty data cached by the kernel may have been dropped on
write-back failure. In that case the only remaining copy of the
data is in the WAL. A subsequent fsync() could appear to succeed,
but not have flushed the data. That means that a future checkpoint
could apparently complete successfully but have lost data.
Therefore, violently prevent any future checkpoint attempts by
panicking on the first fsync() failure. Note that we already
did the same for WAL data; this change extends that behavior to
non-temporary data files.
Provide a GUC data_sync_retry to control this new behavior, for
users of operating systems that don't eject dirty data, and possibly
forensic/testing uses. If it is set to on and the write-back error
was transient, a later checkpoint might genuinely succeed (on a
system that does not throw away buffers on failure); if the error is
permanent, later checkpoints will continue to fail. The GUC defaults
to off, meaning that we panic.
Back-patch to all supported releases.
There is still a narrow window for error-loss on some operating
systems: if the file is closed and later reopened and a write-back
error occurs in the intervening time, but the inode has the bad
luck to be evicted due to memory pressure before we reopen, we could
miss the error. A later patch will address that with a scheme
for keeping files with dirty data open at all times, but we judge
that to be too complicated to back-patch.
Author: Craig Ringer, with some adjustments by Thomas Munro
Reported-by: Craig Ringer
Reviewed-by: Robert Haas, Thomas Munro, Andres Freund
Discussion: https://postgr.es/m/20180427222842.in2e4mibx45zdth5%40alap3.anarazel.de
M doc/src/sgml/config.sgml
M src/backend/access/heap/rewriteheap.c
M src/backend/access/transam/slru.c
M src/backend/access/transam/timeline.c
M src/backend/access/transam/xlog.c
M src/backend/replication/logical/snapbuild.c
M src/backend/storage/file/fd.c
M src/backend/storage/smgr/md.c
M src/backend/utils/cache/relmapper.c
M src/backend/utils/misc/guc.c
M src/backend/utils/misc/postgresql.conf.sample
M src/include/storage/fd.h
Don't forget about failed fsync() requests.
commit : 542e6f3861cee1a5bd2974c318d2e05cc95d8a63
author : Thomas Munro <[email protected]>
date : Mon, 19 Nov 2018 13:37:49 +1300
committer: Thomas Munro <[email protected]>
date : Mon, 19 Nov 2018 13:37:49 +1300
If fsync() fails, md.c must keep the request in its bitmap, so that
future attempts will try again.
Back-patch to all supported releases.
Author: Thomas Munro
Reviewed-by: Amit Kapila
Reported-by: Andrew Gierth
Discussion: https://postgr.es/m/87y3i1ia4w.fsf%40news-spur.riddles.org.uk
M src/backend/storage/smgr/md.c
Fix AC_REQUIRES breakage in LLVM autoconf tests.
commit : b81ef6386ea890423f1f15a67ff3bc679f9f63d6
author : Tom Lane <[email protected]>
date : Sat, 17 Nov 2018 23:16:00 -0500
committer: Tom Lane <[email protected]>
date : Sat, 17 Nov 2018 23:16:00 -0500
Any Autoconf macro that uses AC_REQUIRES -- directly or indirectly --
must not be inside a plain shell "if" test; if it is, whatever code
gets pulled in by the AC_REQUIRES will also be inside that "if".
Instead of "if" we can use AS_IF, which knows how to get this right
(cf commit 01051a987).
The only immediate problem from getting this wrong was that AC_PROG_AWK
had to be run twice, once inside the "if llvm" block and once in the
main line. However, it broke a different patch I'm about to submit
more thoroughly.
M configure
M configure.in
Add valgrind suppressions for wcsrtombs optimizations
commit : bf070ce09e05943d6484de0ec17c7b02f2690a6d
author : Tomas Vondra <[email protected]>
date : Sat, 17 Nov 2018 23:50:21 +0100
committer: Tomas Vondra <[email protected]>
date : Sat, 17 Nov 2018 23:50:21 +0100
wcsrtombs (called through wchar2char from common functions like lower,
upper, etc.) uses various optimizations that may look like access to
uninitialized data, triggering valgrind reports.
For example AVX2 instructions load data in 256-bit chunks, and gconv
does something similar with 32-bit chunks. This is faster than accessing
the bytes one by one, and the uninitialized part of the buffer is not
actually used. So suppress the bogus reports.
The exact stack depends on possible optimizations - it might be AVX, SSE
(as in the report by Aleksander Alekseev) or something else. Hence the
last frame is wildcarded, to deal with this.
Backpatch all the way back to 9.4.
Author: Tomas Vondra
Discussion: https://www.postgresql.org/message-id/flat/90ac0452-e907-e7a4-b3c8-15bd33780e62%402ndquadrant.com
Discussion: https://www.postgresql.org/message-id/[email protected]
M src/tools/valgrind.supp
Correct code comments for PartitionedRelPruneInfo struct
commit : 59f372e082e6564f4629dcbbc235c206e963814d
author : Peter Eisentraut <[email protected]>
date : Thu, 15 Nov 2018 23:04:48 +0100
committer: Peter Eisentraut <[email protected]>
date : Thu, 15 Nov 2018 23:04:48 +0100
The comments above the PartitionedRelPruneInfo struct incorrectly
document how subplan_map and subpart_map are indexed. This seems to
have snuck in on 4e232364033.
Author: David Rowley <[email protected]>
M src/include/nodes/plannodes.h
Update executor documentation for run-time partition pruning
commit : fd5274a65b4fe15c4b8dd66ef6839dc1dbf86a52
author : Peter Eisentraut <[email protected]>
date : Thu, 15 Nov 2018 23:02:21 +0100
committer: Peter Eisentraut <[email protected]>
date : Thu, 15 Nov 2018 23:02:21 +0100
With run-time partition pruning, there is no longer necessarily an
executor node for each corresponding plan node.
Author: David Rowley <[email protected]>
M src/backend/executor/README
Make reformat-dat-files, reformat-dat-files VPATH safe.
commit : 8fbb2a92e014fea609988ed665133333ebf42d39
author : Andres Freund <[email protected]>
date : Thu, 15 Nov 2018 11:35:07 -0800
committer: Andres Freund <[email protected]>
date : Thu, 15 Nov 2018 11:35:07 -0800
The reformat_dat_file.pl script, added by 372728b0d49552641, supported
all the necessary options to make it work in a VPATH build, but the
makefile invocations didn't take VPATH into account. Fix that.
Discussion: https://postgr.es/m/[email protected]
Backpatch: 11-, where 372728b0d49552641 was merged
M src/include/catalog/Makefile
Fix the omission in docs.
commit : e8ba27a4ce7ff4ebed09eeb2dc6cef8b35a590ed
author : Amit Kapila <[email protected]>
date : Thu, 15 Nov 2018 11:09:15 +0530
committer: Amit Kapila <[email protected]>
date : Thu, 15 Nov 2018 11:09:15 +0530
Commit 5373bc2a08 has added type for background workers but forgot to
update at one place in the documentation.
Reported-by: John Naylor
Author: John Naylor
Reviewed-by: Amit Kapila
Backpatch-through: 11
Discussion: https://postgr.es/m/CAJVSVGVmvgJ8Lq4WBxC3zV5wf0txdCqRSgkWVP+jaBF=HgWscA@mail.gmail.com
M doc/src/sgml/monitoring.sgml
Use 64 bit type for BufFileSize().
commit : fa2ceaca435889119f8a40ae7b000cd5229a0dd0
author : Thomas Munro <[email protected]>
date : Thu, 15 Nov 2018 12:34:04 +1300
committer: Thomas Munro <[email protected]>
date : Thu, 15 Nov 2018 12:34:04 +1300
BufFileSize() can't use off_t, because it's only 32 bits wide on
some systems. BufFile objects can have many 1GB segments so the
total size can exceed 2^31. The only known client of the function
is parallel CREATE INDEX, which was reported to fail when building
large indexes on Windows.
Though this is technically an ABI break on platforms with a 32 bit
off_t and we might normally avoid back-patching it, the function is
brand new and thus unlikely to have been discovered by extension
authors yet, and it's fairly thoroughly broken on those platforms
anyway, so just fix it.
Defect in 9da0cc35. Bug #15460. Back-patch to 11, where this
function landed.
Author: Thomas Munro
Reported-by: Paul van der Linden, Pavel Oskin
Reviewed-by: Peter Geoghegan
Discussion: https://postgr.es/m/15460-b6db80de822fa0ad%40postgresql.org
Discussion: https://postgr.es/m/CAHDGBJP_GsESbTt4P3FZA8kMUKuYxjg57XHF7NRBoKnR%3DCAR-g%40mail.gmail.com
M src/backend/storage/file/buffile.c
M src/backend/utils/sort/logtape.c
M src/include/storage/buffile.h
Doc: remove claim that all \pset format options are unique in 1 letter.
commit : b8182d6293d930da527be4ae38bca8e20c47b8a8
author : Tom Lane <[email protected]>
date : Wed, 14 Nov 2018 16:29:57 -0500
committer: Tom Lane <[email protected]>
date : Wed, 14 Nov 2018 16:29:57 -0500
This hasn't been correct since 9.3 added "latex-longtable".
I left the phraseology "Unique abbreviations are allowed" alone.
It's correct as far as it goes, and we are studiously refraining
from specifying exactly what happens if you give a non-unique
abbreviation. (The answer in the back branches is "you get a
backwards-compatible choice", and the answer in HEAD will shortly
be "you get an error", but there seems no need to mention such
details here.)
Daniel Vérité
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/ref/psql-ref.sgml
Second try at fixing numeric data passed through an ECPG SQLDA.
commit : 4618fdd674128ad62096619d449f248b0ecc3ed7
author : Tom Lane <[email protected]>
date : Wed, 14 Nov 2018 11:27:30 -0500
committer: Tom Lane <[email protected]>
date : Wed, 14 Nov 2018 11:27:30 -0500
In commit ecfd55795, I removed sqlda.c's checks for ndigits != 0 on the
grounds that we should duplicate the state of the numeric value's digit
buffer even when all the digits are zeroes. However, that still isn't
quite right, because another possible state of the digit buffer is
buf == digits == NULL (this occurs for a NaN). As the code now stands,
it'll invoke memcpy with a NULL source address and zero bytecount,
which we know a few platforms crash on. Hence, reinstate the no-copy
short-circuit, but make it test specifically for buf != NULL rather than
some other condition. In hindsight, the ndigits test (added by commit
f2ae9f9c3) was almost certainly meant to fix the NaN case not the
all-zeroes case as the associated thread alleged.
As before, back-patch to all supported versions.
Discussion: https://postgr.es/m/1803D792815FC24D871C00D17AE95905C71161@g01jpexmbkw24
M src/interfaces/ecpg/ecpglib/sqlda.c
M src/interfaces/ecpg/test/expected/sql-sqlda.c
M src/interfaces/ecpg/test/expected/sql-sqlda.stderr
M src/interfaces/ecpg/test/expected/sql-sqlda.stdout
M src/interfaces/ecpg/test/sql/sqlda.pgc
Initialize TransactionState and user ID consistently at transaction start
commit : 464dc037ffe7496040fe783a4447c5ce09864100
author : Michael Paquier <[email protected]>
date : Wed, 14 Nov 2018 16:47:51 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 14 Nov 2018 16:47:51 +0900
If a failure happens when a transaction is starting between the moment
the transaction status is changed from TRANS_DEFAULT to TRANS_START and
the moment the current user ID and security context flags are fetched
via GetUserIdAndSecContext(), or before initializing its basic fields,
then those may get reset to incorrect values when the transaction
aborts, leaving the session in an inconsistent state.
One problem reported is that failing a starting transaction at the first
query of a session could cause several kinds of system crashes on the
follow-up queries.
In order to solve that, move the initialization of the transaction state
fields and the call of GetUserIdAndSecContext() in charge of fetching
the current user ID close to the point where the transaction status is
switched to TRANS_START, where there cannot be any error triggered
in-between, per an idea of Tom Lane. This properly ensures that the
current user ID, the security context flags and that the basic fields of
TransactionState remain consistent even if the transaction fails while
starting.
Reported-by: Richard Guo
Diagnosed-By: Richard Guo
Author: Michael Paquier
Reviewed-by: Tom Lane
Discussion: https://postgr.es/m/CAN_9JTxECSb=pEPcb0a8d+6J+bDcOZ4=DgRo_B7Y5gRHJUM=Rw@mail.gmail.com
Backpatch-through: 9.4
M src/backend/access/transam/xact.c
Fix incorrect results for numeric data passed through an ECPG SQLDA.
commit : 68393f3fd6b91f1f61a2bdb4e59eb439256eeb65
author : Tom Lane <[email protected]>
date : Tue, 13 Nov 2018 15:46:08 -0500
committer: Tom Lane <[email protected]>
date : Tue, 13 Nov 2018 15:46:08 -0500
Numeric values with leading zeroes were incorrectly copied into a
SQLDA (SQL Descriptor Area), leading to wrong results in ECPG programs.
Report and patch by Daisuke Higuchi. Back-patch to all supported
versions.
Discussion: https://postgr.es/m/1803D792815FC24D871C00D17AE95905C71161@g01jpexmbkw24
M src/interfaces/ecpg/ecpglib/sqlda.c
M src/interfaces/ecpg/test/expected/sql-sqlda.c
M src/interfaces/ecpg/test/expected/sql-sqlda.stderr
M src/interfaces/ecpg/test/expected/sql-sqlda.stdout
M src/interfaces/ecpg/test/sql/sqlda.pgc
pg_dump: Fix dumping of WITH OIDS tables
commit : b72b4fafb962c5cc1c3d2311b2971a299497202b
author : Peter Eisentraut <[email protected]>
date : Fri, 9 Nov 2018 09:17:25 +0100
committer: Peter Eisentraut <[email protected]>
date : Fri, 9 Nov 2018 09:17:25 +0100
A table with OIDs that was the first in the dump output would not get
dumped with OIDs enabled. Fix that.
The reason was that the currWithOids flag was declared to be bool but
actually also takes a -1 value for "don't know yet". But under
stdbool.h semantics, that is coerced to true, so the required SET
default_with_oids command is not output again. Change the variable
type to char to fix that.
Reported-by: Derek Nelson <[email protected]>
M src/bin/pg_dump/pg_backup_archiver.h
Fix const correctness warning.
commit : f43e679b533cab0f26adbca8d54585b94889ce80
author : Thomas Munro <[email protected]>
date : Tue, 13 Nov 2018 18:32:05 +1300
committer: Thomas Munro <[email protected]>
date : Tue, 13 Nov 2018 18:32:05 +1300
Per buildfarm.
M src/backend/libpq/auth.c
Fix the initialization of atomic variables introduced by the group clearing mechanism.
commit : d4d9f21b64d4290cc6695bcd93a8e4c5fc16badf
author : Amit Kapila <[email protected]>
date : Tue, 13 Nov 2018 11:09:44 +0530
committer: Amit Kapila <[email protected]>
date : Tue, 13 Nov 2018 11:09:44 +0530
Commits 0e141c0fbb and baaf272ac9 introduced initialization of atomic
variables in InitProcess which means that it's not safe to look at those
for backends that aren't currently in use. Fix that by initializing them
during postmaster startup.
Reported-by: Andres Freund
Author: Amit Kapila
Backpatch-through: 9.6
Discussion: https://postgr.es/m/[email protected]
M src/backend/storage/lmgr/proc.c
Fix handling of HBA ldapserver with multiple hostnames.
commit : 6b6c64a96dea5492448aa98cf24eca9325e80371
author : Thomas Munro <[email protected]>
date : Tue, 13 Nov 2018 17:39:36 +1300
committer: Thomas Munro <[email protected]>
date : Tue, 13 Nov 2018 17:39:36 +1300
Commit 35c0754f failed to handle space-separated lists of alternative
hostnames in ldapserver, when building a URI for ldap_initialize()
(OpenLDAP). Such lists need to be expanded to space-separated URIs.
Repair. Back-patch to 11, to fix bug report #15495.
Author: Thomas Munro
Reported-by: Renaud Navarro
Discussion: https://postgr.es/m/15495-2c39fc196c95cd72%40postgresql.org
M src/backend/libpq/auth.c
M src/test/ldap/t/001_auth.pl
Fix possible buffer overrun in hba.c.
commit : 726ca18f94e10c11f8dd3774eb56e76a82729f40
author : Thomas Munro <[email protected]>
date : Tue, 13 Nov 2018 16:27:08 +1300
committer: Thomas Munro <[email protected]>
date : Tue, 13 Nov 2018 16:27:08 +1300
Coverty reports a possible buffer overrun in the code that populates the
pg_hba_file_rules view. It may not be a live bug due to restrictions
on options that can be used together, but let's increase MAX_HBA_OPTIONS
and correct a nearby misleading comment.
Back-patch to 10 where this code arrived.
Reported-by: Julian Hsiao
Discussion: https://postgr.es/m/CADnGQpzbkWdKS2YHNifwAvX5VEsJ5gW49U4o-7UL5pzyTv4vTg%40mail.gmail.com
M src/backend/libpq/hba.c
Limit the number of index clauses considered in choose_bitmap_and().
commit : 15b9d47c8e15d11f26fe02955698edd7eafaeb75
author : Tom Lane <[email protected]>
date : Mon, 12 Nov 2018 11:19:04 -0500
committer: Tom Lane <[email protected]>
date : Mon, 12 Nov 2018 11:19:04 -0500
classify_index_clause_usage() is O(N^2) in the number of distinct index
qual clauses it considers, because of its use of a simple search list to
store them. For nearly all queries, that's fine because only a few clauses
will be considered. But Alexander Kuzmenkov reported a machine-generated
query with 80000 (!) index qual clauses, which caused this code to take
forever. Somewhat remarkably, this is the only O(N^2) behavior we now
have for such a query, so let's fix it.
We can get rid of the O(N^2) runtime for cases like this without much
damage to the functionality of choose_bitmap_and() by separating out
paths with "too many" qual or pred clauses, and deeming them to always
be nonredundant with other paths. Then their clauses needn't go into
the search list, so it doesn't get too long, but we don't lose the
ability to consider bitmap AND plans altogether. I set the threshold
for "too many" to be 100 clauses per path, which should be plenty to
ensure no change in planning behavior for normal queries.
There are other things we could do to make this go faster, but it's not
clear that it's worth any additional effort. 80000 qual clauses require
a whole lot of work in many other places, too.
The code's been like this for a long time, so back-patch to all supported
branches. The troublesome query only works back to 9.5 (in 9.4 it fails
with stack overflow in the parser); so I'm not sure that fixing this in
9.4 has any real-world benefit, but perhaps it does.
Discussion: https://postgr.es/m/[email protected]
M src/backend/optimizer/path/indxpath.c
Fix incorrect author name in release notes
commit : 5f1f59282c498c2dd7f68e70994ea650de514f9c
author : Michael Paquier <[email protected]>
date : Mon, 12 Nov 2018 23:00:47 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 12 Nov 2018 23:00:47 +0900
Author: Alexander Lakhin
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/release-10.sgml
M doc/src/sgml/release-9.5.sgml
M doc/src/sgml/release-9.6.sgml
docs: Adapt wal_segment_size docs to fc49e24fa69.
commit : 431b25c9b123e2b41bab5c43f5e71996d0a7889e
author : Andres Freund <[email protected]>
date : Fri, 9 Nov 2018 19:24:05 -0800
committer: Andres Freund <[email protected]>
date : Fri, 9 Nov 2018 19:24:05 -0800
Before this change the docs weren't adapted to the fact that
wal_segment_size is now measured in bytes, rather than multiples of
wal_block_size.
Author: David Steele
Discussion: https://postgr.es/m/[email protected]
Backpatch: 11-, like fc49e24fa69 itself.
M doc/src/sgml/config.sgml
Fix error-cleanup mistakes in exec_stmt_call().
commit : 8e02ee788fb5a4aa8be9deb5c0af5ab5ac40007b
author : Tom Lane <[email protected]>
date : Fri, 9 Nov 2018 22:04:14 -0500
committer: Tom Lane <[email protected]>
date : Fri, 9 Nov 2018 22:04:14 -0500
Commit 15c729347 was a couple bricks shy of a load: we need to
ensure that expr->plan gets reset to NULL on any error exit,
if it's not supposed to be saved. Also ensure that the
stmt->target calculation gets redone if needed.
The easy way to exhibit a problem is to set up code that
violates the writable-argument restriction and then execute
it twice. But error exits out of, eg, setup_param_list()
could also break it. Make the existing PG_TRY block cover
all of that code to be sure.
Per report from Pavel Stehule.
Discussion: https://postgr.es/m/CAFj8pRAeXNTO43W2Y0Cn0YOVFPv1WpYyOqQrrzUiN6s=dn7gCg@mail.gmail.com
M src/pl/plpgsql/src/pl_exec.c
Fix missing role dependencies for some schema and type ACLs.
commit : 1b55acb2cf48341822261bf9c36785be5ee275db
author : Tom Lane <[email protected]>
date : Fri, 9 Nov 2018 20:42:03 -0500
committer: Tom Lane <[email protected]>
date : Fri, 9 Nov 2018 20:42:03 -0500
This patch fixes several related cases in which pg_shdepend entries were
never made, or were lost, for references to roles appearing in the ACLs of
schemas and/or types. While that did no immediate harm, if a referenced
role were later dropped, the drop would be allowed and would leave a
dangling reference in the object's ACL. That still wasn't a big problem
for normal database usage, but it would cause obscure failures in
subsequent dump/reload or pg_upgrade attempts, taking the form of
attempts to grant privileges to all-numeric role names. (I think I've
seen field reports matching that symptom, but can't find any right now.)
Several cases are fixed here:
1. ALTER DOMAIN SET/DROP DEFAULT would lose the dependencies for any
existing ACL entries for the domain. This case is ancient, dating
back as far as we've had pg_shdepend tracking at all.
2. If a default type privilege applies, CREATE TYPE recorded the
ACL properly but forgot to install dependency entries for it.
This dates to the addition of default privileges for types in 9.2.
3. If a default schema privilege applies, CREATE SCHEMA recorded the
ACL properly but forgot to install dependency entries for it.
This dates to the addition of default privileges for schemas in v10
(commit ab89e465c).
Another somewhat-related problem is that when creating a relation
rowtype or implicit array type, TypeCreate would apply any available
default type privileges to that type, which we don't really want
since such an object isn't supposed to have privileges of its own.
(You can't, for example, drop such privileges once they've been added
to an array type.)
ab89e465c is also to blame for a race condition in the regression tests:
privileges.sql transiently installed globally-applicable default
privileges on schemas, which sometimes got absorbed into the ACLs of
schemas created by concurrent test scripts. This should have resulted
in failures when privileges.sql tried to drop the role holding such
privileges; but thanks to the bug fixed here, it instead led to dangling
ACLs in the final state of the regression database. We'd managed not to
notice that, but it became obvious in the wake of commit da906766c, which
allowed the race condition to occur in pg_upgrade tests.
To fix, add a function recordDependencyOnNewAcl to encapsulate what
callers of get_user_default_acl need to do; while the original call
sites got that right via ad-hoc code, none of the later-added ones
have. Also change GenerateTypeDependencies to generate these
dependencies, which requires adding the typacl to its parameter list.
(That might be annoying if there are any extensions calling that
function directly; but if there are, they're most likely buggy in the
same way as the core callers were, so they need work anyway.) While
I was at it, I changed GenerateTypeDependencies to accept most of its
parameters in the form of a Form_pg_type pointer, making its parameter
list a bit less unwieldy and mistake-prone.
The test race condition is fixed just by wrapping the addition and
removal of default privileges into a single transaction, so that that
state is never visible externally. We might eventually prefer to
separate out tests of default privileges into a script that runs by
itself, but that would be a bigger change and would make the tests
run slower overall.
Back-patch relevant parts to all supported branches.
Discussion: https://postgr.es/m/[email protected]
M src/backend/catalog/aclchk.c
M src/backend/catalog/heap.c
M src/backend/catalog/pg_namespace.c
M src/backend/catalog/pg_proc.c
M src/backend/catalog/pg_type.c
M src/backend/commands/typecmds.c
M src/include/catalog/pg_type.h
M src/include/utils/acl.h
M src/test/regress/expected/privileges.out
M src/test/regress/sql/privileges.sql
Fix dependency handling of partitions and inheritance for ON COMMIT
commit : 84b4a0cf6619b88bff1b20e8bf612b1c09f150fd
author : Michael Paquier <[email protected]>
date : Fri, 9 Nov 2018 10:03:31 +0900
committer: Michael Paquier <[email protected]>
date : Fri, 9 Nov 2018 10:03:31 +0900
This commit fixes a set of issues with ON COMMIT actions when used on
partitioned tables and tables with inheritance children:
- Applying ON COMMIT DROP on a partitioned table with partitions or on a
table with inheritance children caused a failure at commit time, with
complains about the children being already dropped as all relations are
dropped one at the same time.
- Applying ON COMMIT DELETE on a partition relying on a partitioned
table which uses ON COMMIT DROP would cause the partition truncation to
fail as the parent is removed first.
The solution to the first problem is to handle the removal of all the
dependencies in one go instead of dropping relations one-by-one, based
on a suggestion from Álvaro Herrera. So instead all the relation OIDs
to remove are gathered and then processed in one round of multiple
deletions.
The solution to the second problem is to reorder the actions, with
truncation happening first and relation drop done after. Even if it
means that a partition could be first truncated, then immediately
dropped if its partitioned table is dropped, this has the merit to keep
the code simple as there is no need to do existence checks on the
relations to drop.
Contrary to a manual TRUNCATE on a partitioned table, ON COMMIT DELETE
does not cascade to its partitions. The ON COMMIT action defined on
each partition gets the priority.
Author: Michael Paquier
Reviewed-by: Amit Langote, Álvaro Herrera, Robert Haas
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 10
M doc/src/sgml/ref/create_table.sgml
M src/backend/commands/tablecmds.c
M src/test/regress/expected/temp.out
M src/test/regress/sql/temp.sql
Disallow setting client_min_messages higher than ERROR.
commit : 7b08b4a8adbbc5a5b022e9dd6e658d03ceb31afd
author : Tom Lane <[email protected]>
date : Thu, 8 Nov 2018 17:33:25 -0500
committer: Tom Lane <[email protected]>
date : Thu, 8 Nov 2018 17:33:25 -0500
Previously it was possible to set client_min_messages to FATAL or PANIC,
which had the effect of suppressing transmission of regular ERROR messages
to the client. Perhaps that seemed like a useful option in the past, but
the trouble with it is that it breaks guarantees that are explicitly made
in our FE/BE protocol spec about how a query cycle can end. While libpq
and psql manage to cope with the omission, that's mostly because they
are not very bright; client libraries that have more semantic knowledge
are likely to get confused. Notably, pgODBC doesn't behave very sanely.
Let's fix this by getting rid of the ability to set client_min_messages
above ERROR.
In HEAD, just remove the FATAL and PANIC options from the set of allowed
enum values for client_min_messages. (This change also affects
trace_recovery_messages, but that's OK since these aren't useful values
for that variable either.)
In the back branches, there was concern that rejecting these values might
break applications that are explicitly setting things that way. I'm
pretty skeptical of that argument, but accommodate it by accepting these
values and then internally setting the variable to ERROR anyway.
In all branches, this allows a couple of tiny simplifications in the
logic in elog.c, so do that.
Also respond to the point that was made that client_min_messages has
exactly nothing to do with the server's logging behavior, and therefore
does not belong in the "When To Log" subsection of the documentation.
The "Statement Behavior" subsection is a better match, so move it there.
Jonah Harris and Tom Lane
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/[email protected]
M doc/src/sgml/config.sgml
M src/backend/utils/error/elog.c
M src/backend/utils/misc/guc.c
M src/backend/utils/misc/postgresql.conf.sample
Revise attribute handling code on partition creation
commit : e0c05bf4a7e6b6327d02da4ca67fc2a41d9e6548
author : Alvaro Herrera <[email protected]>
date : Thu, 8 Nov 2018 16:22:09 -0300
committer: Alvaro Herrera <[email protected]>
date : Thu, 8 Nov 2018 16:22:09 -0300
The original code to propagate NOT NULL and default expressions
specified when creating a partition was mostly copy-pasted from
typed-tables creation, but not being a great match it contained some
duplicity, inefficiency and bugs.
This commit fixes the bug that NOT NULL constraints declared in the
parent table would not be honored in the partition. One reported issue
that is not fixed is that a DEFAULT declared in the child is not used
when inserting through the parent. That would amount to a behavioral
change that's better not back-patched.
This rewrite makes the code simpler:
1. instead of checking for duplicate column names in its own block,
reuse the original one that already did that;
2. instead of concatenating the list of columns from parent and the one
declared in the partition and scanning the result to (incorrectly)
propagate defaults and not-null constraints, just scan the latter
searching the former for a match, and merging sensibly. This works
because we know the list in the parent is already correct and there can
only be one parent.
This rewrite makes ColumnDef->is_from_parent unused, so it's removed
on branch master; on released branches, it's kept as an unused field in
order not to cause ABI incompatibilities.
This commit also adds a test case for creating partitions with
collations mismatching that on the parent table, something that is
closely related to the code being patched. No code change is introduced
though, since that'd be a behavior change that could break some (broken)
working applications.
Amit Langote wrote a less invasive fix for the original
NOT NULL/defaults bug, but while I kept the tests he added, I ended up
not using his original code. Ashutosh Bapat reviewed Amit's fix. Amit
reviewed mine.
Author: Álvaro Herrera, Amit Langote
Reviewed-by: Ashutosh Bapat, Amit Langote
Reported-by: Jürgen Strobel (bug #15212)
Discussion: https://postgr.es/m/[email protected]
M src/backend/commands/sequence.c
M src/backend/commands/tablecmds.c
M src/backend/nodes/equalfuncs.c
M src/backend/nodes/makefuncs.c
M src/backend/parser/gram.y
M src/backend/parser/parse_utilcmd.c
M src/include/nodes/parsenodes.h
M src/test/regress/expected/create_table.out
M src/test/regress/sql/create_table.sql