Stamp 9.6.15.
commit : 86ca7f81f7dfc17f04698189dec8973d358bc711
author : Tom Lane <[email protected]>
date : Mon, 5 Aug 2019 17:18:48 -0400
committer: Tom Lane <[email protected]>
date : Mon, 5 Aug 2019 17:18:48 -0400 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 : 3354bd5e2ba921d8267dbd6cac90b491a4f27cae
author : Tom Lane <[email protected]>
date : Mon, 5 Aug 2019 11:49:14 -0400
committer: Tom Lane <[email protected]>
date : Mon, 5 Aug 2019 11:49:14 -0400 Security: CVE-2019-10208, CVE-2019-10209 M doc/src/sgml/release-9.6.sgml
Require the schema qualification in pg_temp.type_name(arg).
commit : 7da46192dd7e95326d1b83a2ddcda420c1cefcae
author : Noah Misch <[email protected]>
date : Mon, 5 Aug 2019 07:48:41 -0700
committer: Noah Misch <[email protected]>
date : Mon, 5 Aug 2019 07:48:41 -0700 Commit aa27977fe21a7dfa4da4376ad66ae37cb8f0d0b5 introduced this
restriction for pg_temp.function_name(arg); do likewise for types
created in temporary schemas. Programs that this breaks should add
"pg_temp." schema qualification or switch to arg::type_name syntax.
Back-patch to 9.4 (all supported versions).
Reviewed by Tom Lane. Reported by Tom Lane.
Security: CVE-2019-10208 M doc/src/sgml/config.sgml
M src/backend/catalog/namespace.c
M src/backend/parser/parse_func.c
M src/backend/parser/parse_type.c
M src/backend/utils/adt/ruleutils.c
M src/include/catalog/namespace.h
M src/include/parser/parse_type.h
M src/test/regress/expected/temp.out
M src/test/regress/sql/temp.sql
Translation updates
commit : 76c096bc06af053bc17be2c3ac99577cef52546a
author : Peter Eisentraut <[email protected]>
date : Mon, 5 Aug 2019 15:40:51 +0200
committer: Peter Eisentraut <[email protected]>
date : Mon, 5 Aug 2019 15:40:51 +0200 Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 9e5626e1043405479299c3e23754614b43ad4d0f M src/backend/po/ru.po
M src/backend/po/tr.po
M src/bin/initdb/po/ru.po
M src/bin/initdb/po/tr.po
M src/bin/pg_dump/po/ru.po
M src/bin/scripts/po/ru.po
M src/interfaces/libpq/po/ru.po
Fix tab completion for ALTER LANGUAGE in psql
commit : dd64a45a7d5982a6e0ef4569f0f16507db93136e
author : Michael Paquier <[email protected]>
date : Mon, 5 Aug 2019 14:30:34 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 5 Aug 2019 14:30:34 +0900 OWNER_TO was used for the completion, which is not a supported grammar,
but OWNER TO is.
This error has been introduced by d37b816, so backpatch down to 9.6.
Author: Alexander Lakhin
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6 M src/bin/psql/tab-complete.c
Release notes for 11.5, 10.10, 9.6.15, 9.5.19, 9.4.24.
commit : 6138386dcbd12831c5fb9f9b65e75cfeb407147b
author : Tom Lane <[email protected]>
date : Sun, 4 Aug 2019 17:08:42 -0400
committer: Tom Lane <[email protected]>
date : Sun, 4 Aug 2019 17:08:42 -0400 M doc/src/sgml/release-9.6.sgml
Fix handling of previous password hooks in passwordcheck
commit : 957b822b5294bd3e19aab21b6cb937822db11673
author : Michael Paquier <[email protected]>
date : Thu, 1 Aug 2019 09:38:20 +0900
committer: Michael Paquier <[email protected]>
date : Thu, 1 Aug 2019 09:38:20 +0900 When piling up loading of modules using check_password_hook_type,
loading passwordcheck would remove any trace of a previously-loaded
hook. Unloading the module would also cause previous hooks to be
entirely gone.
Reported-by: Rafael Castro
Author: Michael Paquier
Reviewed-by: Daniel Gustafsson
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4 M contrib/passwordcheck/passwordcheck.c
Fix pg_dump's handling of dependencies for custom opclasses.
commit : b31a9802262ccfd7115faecbc34114f793f96e8d
author : Tom Lane <[email protected]>
date : Wed, 31 Jul 2019 15:42:50 -0400
committer: Tom Lane <[email protected]>
date : Wed, 31 Jul 2019 15:42:50 -0400 Since pg_dump doesn't treat the member operators and functions of operator
classes/families (that is, the pg_amop and pg_amproc entries, not the
underlying operators/functions) as separate dumpable objects, it missed
their dependency information. I think this was safe when the code was
designed, because the default object sorting rule emits operators and
functions before opclasses, and there were no dependency types that could
mess that up. However, the introduction of range types in 9.2 broke it:
now a type can have a dependency on an opclass, allowing dependency rules
to push the opclass before the type and hence before custom operators.
Lacking any information showing that it shouldn't do so, pg_dump emitted
the objects in the wrong order.
Fix by teaching getDependencies() to translate pg_depend entries for
pg_amop/amproc rows to look like dependencies for their parent opfamily.
I added a regression test for this in HEAD/v12, but not further back;
life is too short to fight with 002_pg_dump.pl.
Per bug #15934 from Tom Gottfried. Back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected] M src/bin/pg_dump/pg_dump.c
Print WAL position correctly in pg_rewind error message.
commit : 08e0c08678fa0286c8edaf478c395a6393682fe8
author : Heikki Linnakangas <[email protected]>
date : Tue, 30 Jul 2019 21:14:14 +0300
committer: Heikki Linnakangas <[email protected]>
date : Tue, 30 Jul 2019 21:14:14 +0300 This has been wrong ever since pg_rewind was added. The if-branch just
above this, where we print the same error with an extra message supplied
by XLogReadRecord() got this right, but the variable name was wrong in the
else-branch. As a consequence, the error printed the WAL position as
0/0 if there was an error reading a WAL file.
Backpatch to 9.5, where pg_rewind was added. M src/bin/pg_rewind/parsexlog.c
Fix busted logic for parallel lock grouping in TopoSort().
commit : c3b613e1b0e5a83e36ffb14089bad1d4a5880208
author : Tom Lane <[email protected]>
date : Mon, 29 Jul 2019 18:49:04 -0400
committer: Tom Lane <[email protected]>
date : Mon, 29 Jul 2019 18:49:04 -0400 A "break" statement erroneously left behind by commit a1c1af2a1
caused TopoSort to do the wrong thing if a lock's wait list
contained multiple members of the same locking group.
Because parallel workers don't normally need any locks not already
taken by their leader, this is very hard --- maybe impossible ---
to hit in production. Still, if it did happen, the queries involved
in an otherwise-resolvable deadlock would block until canceled.
In addition to removing the bogus "break", add an Assert showing
that the conflicting uses of the beforeConstraints[] array (for both
counts and flags) don't overlap, and add some commentary explaining
why not; because it's not obvious without explanation, IMHO.
Original report and patch from Rui Hai Jiang; additional assert
and commentary by me. Back-patch to 9.6 where the bug came in.
Discussion: https://postgr.es/m/CAEri+mLd3bpHLyW+a9pSe1y=aEkeuJpwBSwvo-+m4n7-ceRmXw@mail.gmail.com M src/backend/storage/lmgr/deadlock.c
Doc: Fix event trigger firing table
commit : 484a4667bbed9c0c3ee47a41a75ea8d7c48444e5
author : Michael Paquier <[email protected]>
date : Sun, 28 Jul 2019 22:02:45 +0900
committer: Michael Paquier <[email protected]>
date : Sun, 28 Jul 2019 22:02:45 +0900 The table has not been updated for some commands introduced in recent
releases, so refresh it. While on it, reorder entries alphabetically.
Backpatch all the way down for all the commands which have gone
missing.
Reported-by: Jeremy Smith
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4 M doc/src/sgml/event-trigger.sgml
Don't uselessly escape a string that doesn't need escaping
commit : 0f9133b66b567312f23e39eb767d6e6546aa590d
author : Alvaro Herrera <[email protected]>
date : Fri, 26 Jul 2019 17:46:40 -0400
committer: Alvaro Herrera <[email protected]>
date : Fri, 26 Jul 2019 17:46:40 -0400 Per gripe from Ian Barwick
Co-authored-by: Ian Barwick <[email protected]>
Discussion: https://postgr.es/m/CABvVfJWNnNKb8cHsTLhkTsvL1+G6BVcV+57+w1JZ61p8YGPdWQ@mail.gmail.com M src/bin/pg_basebackup/pg_basebackup.c
Tweak our special-case logic for the IANA "Factory" timezone.
commit : f6c7c64e9fc8cdc8217fbc46a00e94b4e33856d2
author : Tom Lane <[email protected]>
date : Fri, 26 Jul 2019 13:07:08 -0400
committer: Tom Lane <[email protected]>
date : Fri, 26 Jul 2019 13:07:08 -0400 pg_timezone_names() tries to avoid showing the "Factory" zone in
the view, mainly because that has traditionally had a very long
"abbreviation" such as "Local time zone must be set--see zic manual page",
so that showing it messes up psql's formatting of the whole view.
Since tzdb version 2016g, IANA instead uses the abbreviation "-00",
which is sane enough that there's no reason to discriminate against it.
On the other hand, it emerges that FreeBSD and possibly other packagers
are so wedded to backwards compatibility that they hack the IANA data
to keep the old spelling --- and not just that old spelling, but even
older spellings that IANA used back in the stone age. This caused the
filter logic to fail to suppress "Factory" at all on such platforms,
though the formatting problem is definitely real in that case.
To solve both problems, get rid of the hard-wired assumption about
exactly what Factory's abbreviation is, and instead reject abbreviations
exceeding 31 characters. This will allow Factory to appear in the view
if and only if it's using the modern abbreviation.
In passing, simplify the code we add to zic.c to support "zic -P"
to remove its now-obsolete hacks to not print the Factory zone's
abbreviation. Unlike pg_timezone_names(), there's no reason for
that code to support old/nonstandard timezone data.
Since we generally prefer to keep timezone-related behavior the
same in all branches, and since this is arguably a bug fix,
back-patch to all supported branches.
Discussion: https://postgr.es/m/[email protected] M src/backend/utils/adt/datetime.c
M src/timezone/zic.c
Avoid choosing "localtime" or "posixrules" as TimeZone during initdb.
commit : 51b47471f0f64540752854d3c91a7cd798ac304d
author : Tom Lane <[email protected]>
date : Fri, 26 Jul 2019 12:45:32 -0400
committer: Tom Lane <[email protected]>
date : Fri, 26 Jul 2019 12:45:32 -0400 Some platforms create a file named "localtime" in the system
timezone directory, making it a copy or link to the active time
zone file. If Postgres is built with --with-system-tzdata, initdb
will see that file as an exact match to localtime(3)'s behavior,
and it may decide that "localtime" is the most preferred spelling of
the active zone. That's a very bad choice though, because it's
neither informative, nor portable, nor stable if someone changes
the system timezone setting. Extend the preference logic added by
commit e3846a00c so that we will prefer any other zone file that
matches localtime's behavior over "localtime".
On the same logic, also discriminate against "posixrules", which
is another not-really-a-zone file that is often present in the
timezone directory. (Since we install "posixrules" but not
"localtime", this change can affect the behavior of Postgres
with or without --with-system-tzdata.)
Note that this change doesn't prevent anyone from choosing these
pseudo-zones if they really want to (i.e., by setting TZ for initdb,
or modifying the timezone GUC later on). It just prevents initdb
from preferring these zone names when there are multiple matches to
localtime's behavior.
Since we generally prefer to keep timezone-related behavior the
same in all branches, and since this is arguably a bug fix,
back-patch to all supported branches.
Discussion: https://postgr.es/m/CADT4RqCCnj6FKLisvT8tTPfTP4azPhhDFJqDF1JfBbOH5w4oyQ@mail.gmail.com
Discussion: https://postgr.es/m/[email protected] M src/bin/initdb/findtimezone.c
Fix loss of fractional digits for large values in cash_numeric().
commit : 30bed9f63823a13cd3fe5b1361b7f30f7123c003
author : Tom Lane <[email protected]>
date : Fri, 26 Jul 2019 11:59:00 -0400
committer: Tom Lane <[email protected]>
date : Fri, 26 Jul 2019 11:59:00 -0400 Money values exceeding about 18 digits (depending on lc_monetary)
could be inaccurately converted to numeric, due to select_div_scale()
deciding it didn't need to compute any fractional digits. Force
its hand by setting the dscale of one division input to equal the
number of fractional digits we need.
In passing, rearrange the logic to not do useless work in locales
where money values are considered integral.
Per bug #15925 from Slawomir Chodnicki. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected] M src/backend/utils/adt/cash.c
M src/test/regress/expected/money.out
M src/test/regress/sql/money.sql
Fix syntax error in commit 20e99cddd.
commit : 3f1c6d0482e2e19e634b5f13fc2bda5ca805f8d9
author : Tom Lane <[email protected]>
date : Thu, 25 Jul 2019 14:42:02 -0400
committer: Tom Lane <[email protected]>
date : Thu, 25 Jul 2019 14:42:02 -0400 Per buildfarm. M src/tools/msvc/MSBuildProject.pm
Fix failures to ignore \r when reading Windows-style newlines.
commit : ba27151d1eb0b36bf7ede900973a10cd0b54c054
author : Tom Lane <[email protected]>
date : Thu, 25 Jul 2019 12:10:55 -0400
committer: Tom Lane <[email protected]>
date : Thu, 25 Jul 2019 12:10:55 -0400 libpq failed to ignore Windows-style newlines in connection service files.
This normally wasn't a problem on Windows itself, because fgets() would
convert \r\n to just \n. But if libpq were running inside a program that
changes the default fopen mode to binary, it would see the \r's and think
they were data. In any case, it's project policy to ignore \r in text
files unconditionally, because people sometimes try to use files with
DOS-style newlines on Unix machines, where the C library won't hide that
from us.
Hence, adjust parseServiceFile() to ignore \r as well as \n at the end of
the line. In HEAD, go a little further and make it ignore all trailing
whitespace, to match what it's always done with leading whitespace.
In HEAD, also run around and fix up everyplace where we have
newline-chomping code to make all those places look consistent and
uniformly drop \r. It is not clear whether any of those changes are
fixing live bugs. Most of the non-cosmetic changes are in places that
are reading popen output, and the jury is still out as to whether popen
on Windows can return \r\n. (The Windows-specific code in pipe_read_line
seems to think so, but our lack of support for this elsewhere suggests
maybe it's not a problem in practice.) Hence, I desisted from applying
those changes to back branches, except in run_ssl_passphrase_command()
which is new enough and little-tested enough that we'd probably not have
heard about any problems there.
Tom Lane and Michael Paquier, per bug #15827 from Jorge Gustavo Rocha.
Back-patch the parseServiceFile() change to all supported branches,
and the run_ssl_passphrase_command() change to v11 where that was added.
Discussion: https://postgr.es/m/[email protected] M src/interfaces/libpq/fe-connect.c
Honor MSVC WindowsSDKVersion if set
commit : 09fa171600b0f67fe32a913bda1f64f2407e6dfe
author : Andrew Dunstan <[email protected]>
date : Thu, 25 Jul 2019 11:24:23 -0400
committer: Andrew Dunstan <[email protected]>
date : Thu, 25 Jul 2019 11:24:23 -0400 Add a line to the project file setting the target SDK. Otherwise, in for
example VS2017, if the default but optional 8.1 SDK is not installed the
build will fail.
Patch from Peifeng Qiu, slightly edited by me.
Discussion: https://postgr.es/m/CABmtVJhw1boP_bd4=b3Qv5YnqEdL696NtHFi2ruiyQ6mFHkeQQ@mail.gmail.com
Backpatch to all live branches. M src/tools/msvc/MSBuildProject.pm
Fix contrib/sepgsql test policy to work with latest SELinux releases.
commit : 0a9ba5baac7da710972d507ab3b59a3dc1951319
author : Tom Lane <[email protected]>
date : Thu, 25 Jul 2019 11:02:43 -0400
committer: Tom Lane <[email protected]>
date : Thu, 25 Jul 2019 11:02:43 -0400 As of Fedora 30, it seems that the system-provided macros for setting
up user privileges in SELinux policies don't grant the ability to read
/etc/passwd, as they formerly did. This restriction breaks psql
(which tries to use getpwuid() to obtain the user name it's running
under) and thereby the contrib/sepgsql regression test. Add explicit
specifications that we need the right to read /etc/passwd.
Mike Palmiotto, per a report from me. Back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected] M contrib/sepgsql/sepgsql-regtest.te
Fix failure with pgperlcritic from the TAP test of synchronous replication
commit : 781568ede6062400acadde6a6b0056ada1c8a4c1
author : Michael Paquier <[email protected]>
date : Thu, 25 Jul 2019 07:55:43 +0900
committer: Michael Paquier <[email protected]>
date : Thu, 25 Jul 2019 07:55:43 +0900 Oversight in 7d81bdc, which introduced a new routine in perl lacking a
return clause. Per buildfarm member crake.
Backpatch down to 9.6 like its parent.
Reported-by: Andrew Dunstan
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6 M src/test/recovery/t/007_sync_rep.pl
Fix build of documentation
commit : 2315a261de159e843cf970714ddd6042a9a8a23f
author : Michael Paquier <[email protected]>
date : Wed, 24 Jul 2019 16:02:28 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 24 Jul 2019 16:02:28 +0900 Oversight in 1c42346, which has incorrectly shaped a <xref> markup.
Only v10 and v9.6 got broken.
Reported-by: Stefan Kaltenbrunner
Discussion: https://postgr.es/m/[email protected] M doc/src/sgml/ref/pg_receivexlog.sgml
Doc: Clarify interactions of pg_receivexlog with remote_apply
commit : 4a25ed16400c01fb64c23d2d6f413af95b4e28f8
author : Michael Paquier <[email protected]>
date : Wed, 24 Jul 2019 11:26:52 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 24 Jul 2019 11:26:52 +0900 Using pg_receivexlog with synchronous_commit = remote_apply set in the
backend is incompatible if pg_receivexlog is a synchronous standby as it
never applies WAL, so document this problem and solutions to it.
Backpatch to 9.6, where remote_apply has been added.
Author: Robert Haas, Jesper Pedersen
Reviewed-by: Laurenz Albe, Álvaro Herrera, Michael Paquier
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6 M doc/src/sgml/ref/pg_receivexlog.sgml
Improve stability of TAP test for synchronous replication
commit : c6f961bbbb202bd99053524efdd40fcd70e0aa4f
author : Michael Paquier <[email protected]>
date : Wed, 24 Jul 2019 10:54:39 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 24 Jul 2019 10:54:39 +0900 Slow buildfarm machines have run into issues with this TAP test caused
by a race condition related to the startup of a set of standbys, where
it is possible to finish with an unexpected order in the WAL sender
array of the primary.
This closes the race condition by making sure that any standby started
is registered into the WAL sender array of the primary before starting
the next one based on lookups of pg_stat_replication.
Backpatch down to 9.6 where the test has been introduced.
Author: Michael Paquier
Reviewed-by: Álvaro Herrera, Noah Misch
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6 M src/test/recovery/t/007_sync_rep.pl
Make pg_upgrade's test.sh less chatty.
commit : 75348a733225df4297c924727d25770ed2a1115e
author : Tom Lane <[email protected]>
date : Mon, 22 Jul 2019 17:14:22 -0400
committer: Tom Lane <[email protected]>
date : Mon, 22 Jul 2019 17:14:22 -0400 Remove "set -x", and pass "-A trust" to initdb explicitly,
to suppress almost all of the noise this script used to emit
on stderr.
Back-patch of commit eb9812f27 into all active branches.
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/[email protected] M src/bin/pg_upgrade/test.sh
Silence compiler warning, hopefully.
commit : e480d8350be180410b0a2291b7a9bc08448c7f3e
author : Tom Lane <[email protected]>
date : Fri, 19 Jul 2019 14:48:57 -0400
committer: Tom Lane <[email protected]>
date : Fri, 19 Jul 2019 14:48:57 -0400 Absorb commit e5e04c962a5d12eebbf867ca25905b3ccc34cbe0 from upstream
IANA code, in hopes of silencing warnings from MSVC about negating
a bool value.
Discussion: https://postgr.es/m/[email protected] M src/timezone/zic.c
Fix error in commit e6feef57.
commit : 390bf90f70a835278c7627fb65e4e9039855bcc3
author : Jeff Davis <[email protected]>
date : Thu, 18 Jul 2019 16:53:25 -0700
committer: Jeff Davis <[email protected]>
date : Thu, 18 Jul 2019 16:53:25 -0700 I was careless passing a datum directly to DATE_NOT_FINITE without
calling DatumGetDateADT() first.
Backpatch-through: 9.4 M src/backend/utils/adt/rangetypes.c
Fix daterange canonicalization for +/- infinity.
commit : 56afeb765177ac135a2524551a148c67dc65addb
author : Jeff Davis <[email protected]>
date : Thu, 18 Jul 2019 16:53:17 -0700
committer: Jeff Davis <[email protected]>
date : Thu, 18 Jul 2019 16:53:17 -0700 The values 'infinity' and '-infinity' are a part of the DATE type
itself, so a bound of the date 'infinity' is not the same as an
unbounded/infinite range. However, it is still wrong to try to
canonicalize such values, because adding or subtracting one has no
effect. Fix by treating 'infinity' and '-infinity' the same as
unbounded ranges for the purposes of canonicalization (but not other
purposes).
Backpatch to all versions because it is inconsistent with the
documented behavior. Note that this could be an incompatibility for
applications relying on the behavior contrary to the documentation.
Author: Laurenz Albe
Reviewed-by: Thomas Munro
Discussion: https://postgr.es/m/77f24ea19ab802bc9bc60ddbb8977ee2d646aec1.camel%40cybertec.at
Backpatch-through: 9.4 M src/backend/utils/adt/rangetypes.c
M src/test/regress/expected/rangetypes.out
M src/test/regress/sql/rangetypes.sql
Update time zone data files to tzdata release 2019b.
commit : e3441b2a22b2d38f62b7bcbb10682de1acb0b2d6
author : Tom Lane <[email protected]>
date : Wed, 17 Jul 2019 19:15:21 -0400
committer: Tom Lane <[email protected]>
date : Wed, 17 Jul 2019 19:15:21 -0400 Brazil no longer observes DST.
Historical corrections for Palestine, Hong Kong, and Italy. M src/timezone/data/tzdata.zi
Sync our copy of the timezone library with IANA release tzcode2019b.
commit : 22e73dea3be640f17edbb9a7f1b60cec99247178
author : Tom Lane <[email protected]>
date : Wed, 17 Jul 2019 18:26:24 -0400
committer: Tom Lane <[email protected]>
date : Wed, 17 Jul 2019 18:26:24 -0400 A large fraction of this diff is just due to upstream's somewhat
random decision to rename a bunch of internal variables and struct
fields. However, there is an interesting new feature in zic:
it's grown a "-b slim" option that emits zone files without 32-bit
data and other backwards-compatibility hacks. We should consider
whether we wish to enable that. M src/timezone/README
M src/timezone/localtime.c
M src/timezone/pgtz.h
M src/timezone/tzfile.h
M src/timezone/zic.c
Fix thinko in construction of old_conpfeqop list.
commit : a6e7eb42d6112ba1c1a9b678a913a9de66a11ff9
author : Tom Lane <[email protected]>
date : Tue, 16 Jul 2019 18:17:47 -0400
committer: Tom Lane <[email protected]>
date : Tue, 16 Jul 2019 18:17:47 -0400 This should lappend the OIDs, not lcons them; the existing code produced
a list in reversed order. This is harmless for single-key FKs or FKs
where all the key columns are of the same type, which probably explains
how it went unnoticed. But if those conditions are not met,
ATAddForeignKeyConstraint would make the wrong decision about whether an
existing FK needs to be revalidated. I think it would almost always err
in the safe direction by revalidating a constraint that didn't need it.
You could imagine scenarios where the pfeqop check was fooled by
swapping the types of two FK columns in one ALTER TABLE, but that case
would probably be rejected by other tests, so it might be impossible to
get to the worst-case scenario where an FK should be revalidated and
isn't. (And even then, it's likely to be fine, unless there are weird
inconsistencies in the equality behavior of the replacement types.)
However, this is a performance bug at least.
Noted while poking around to see whether lcons calls could be converted
to lappend.
This bug is old, dating to commit cb3a7c2b9, so back-patch to all
supported branches. M src/backend/commands/tablecmds.c
doc: mention pg_reload_conf() for reloading the config file
commit : 63d1bc04d1fd0b99abba4b4d741494c68d86a68f
author : Bruce Momjian <[email protected]>
date : Mon, 15 Jul 2019 20:57:24 -0400
committer: Bruce Momjian <[email protected]>
date : Mon, 15 Jul 2019 20:57:24 -0400 Reported-by: Ian Barwick
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4 M doc/src/sgml/client-auth.sgml
Fix documentation for pgbench tpcb-like.
commit : 9dcf6d178a5119314b6bce604530072dc48022ce
author : Thomas Munro <[email protected]>
date : Sun, 14 Jul 2019 14:19:54 +1200
committer: Thomas Munro <[email protected]>
date : Sun, 14 Jul 2019 14:19:54 +1200 We choose a random value for delta, not balance. Back-patch to 9.6 where
the mistake arrived.
Author: Fabien Coelho
Discussion: https://postgr.es/m/alpine.DEB.2.21.1904081752210.5867@lancre M doc/src/sgml/ref/pgbench.sgml
Fix variable initialization when using buffering build with GiST
commit : 6365f3ca24b821b1da21bf5b8f01fca73372de66
author : Michael Paquier <[email protected]>
date : Wed, 10 Jul 2019 15:15:18 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 10 Jul 2019 15:15:18 +0900 This can cause valgrind to complain, as the flag marking a buffer as a
temporary copy was not getting initialized.
While on it, fill in with zeros newly-created buffer pages. This does
not matter when loading a block from a temporary file, but it makes the
push of an index tuple into a new buffer page safer.
This has been introduced by 1d27dcf, so backpatch all the way down to
9.4.
Author: Alexander Lakhin
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4 M src/backend/access/gist/gistbuildbuffers.c
Don't remove surplus columns from GROUP BY for inheritance parents
commit : 388d05a5e1551e34e3908c2bfad21860adfcc5a7
author : David Rowley <[email protected]>
date : Wed, 3 Jul 2019 23:46:26 +1200
committer: David Rowley <[email protected]>
date : Wed, 3 Jul 2019 23:46:26 +1200 d4c3a156c added code to remove columns that were not part of a table's
PRIMARY KEY constraint from the GROUP BY clause when all the primary key
columns were present in the group by. This is fine to do since we know
that there will only be one row per group coming from this relation.
However, the logic failed to consider inheritance parent relations. These
can have child relations without a primary key, but even if they did, they
could duplicate one of the parent's rows or one from another child
relation. In this case, those additional GROUP BY columns are required.
Fix this by disabling the optimization for inheritance parent tables.
In v11 and beyond, partitioned tables are fine since partitions cannot
overlap and before v11 partitioned tables could not have a primary key.
Reported-by: Manuel Rigger
Discussion: http://postgr.es/m/CA+u7OA7VLKf_vEr6kLF3MnWSA9LToJYncgpNX2tQ-oWzYCBQAw@mail.gmail.com
Backpatch-through: 9.6 M src/backend/optimizer/plan/planner.c
M src/test/regress/expected/aggregates.out
M src/test/regress/sql/aggregates.sql
Add support for Visual Studio 2019 in build scripts
commit : 78aaffd285c4a66452004f8f2c4ff2771cee4cb4
author : Michael Paquier <[email protected]>
date : Wed, 3 Jul 2019 08:58:17 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 3 Jul 2019 08:58:17 +0900 This adjusts the documentation and the scripts related to the versions
of Windows SDK supported.
Author: Haribabu Kommi
Reviewed-by: Andrew Dunstan, Juan José Santamaría Flecha, Michael
Paquier
Discussion: https://postgr.es/m/CAJrrPGcfqXhfPyMrny9apoDU7M1t59dzVAvoJ9AeAh5BJi+UzA@mail.gmail.com
Backpatch-through: 9.4 M doc/src/sgml/install-windows.sgml
M src/tools/msvc/MSBuildProject.pm
M src/tools/msvc/README
M src/tools/msvc/Solution.pm
M src/tools/msvc/VSObjectFactory.pm
Fix tab completion of "SET variable TO|=" to not offer bogus completions.
commit : 47fe7a753db81370056d506703b58a38a9d591b0
author : Tom Lane <[email protected]>
date : Tue, 2 Jul 2019 13:35:14 -0400
committer: Tom Lane <[email protected]>
date : Tue, 2 Jul 2019 13:35:14 -0400 Don't think that the context "UPDATE tab SET var =" is a GUC-setting
command.
If we have "SET var =" but the "var" is not a known GUC variable,
don't offer any completions. The most likely explanation is that
we've misparsed the context and it's not really a GUC-setting command.
Per gripe from Ken Tanzer. Back-patch to 9.6. The issue exists
further back, but before 9.6 the code looks very different and it
doesn't actually know whether the "var" name matches anything,
so I desisted from trying to fix it.
Discussion: https://postgr.es/m/CAD3a31XpXzrZA9TT3BqLSHghdTK+=cXjNCE+oL2Zn4+oWoc=qA@mail.gmail.com M src/bin/psql/tab-complete.c
Don't read fields of a misaligned ExpandedObjectHeader or AnyArrayType.
commit : 2938aa2a5b1cebb41f9e54c1ea289c286139c21e
author : Noah Misch <[email protected]>
date : Sun, 30 Jun 2019 17:34:17 -0700
committer: Noah Misch <[email protected]>
date : Sun, 30 Jun 2019 17:34:17 -0700 UBSan complains about this. Instead, cast to a suitable type requiring
only 4-byte alignment. DatumGetAnyArrayP() already assumes one can cast
between AnyArrayType and ArrayType, so this doesn't introduce a new
assumption. Back-patch to 9.5, where AnyArrayType was introduced.
Reviewed by Tom Lane.
Discussion: https://postgr.es/m/[email protected] M src/backend/utils/adt/arrayfuncs.c
M src/include/utils/array.h
M src/include/utils/arrayaccess.h
M src/include/utils/expandeddatum.h
Repair logic for reordering grouping sets optimization.
commit : 793eb94e31387738c72a8d7d702a6aecc9c5edee
author : Andrew Gierth <[email protected]>
date : Sun, 30 Jun 2019 23:49:29 +0100
committer: Andrew Gierth <[email protected]>
date : Sun, 30 Jun 2019 23:49:29 +0100 The logic in reorder_grouping_sets to order grouping set elements to
match a pre-specified sort ordering was defective, resulting in
unnecessary sort nodes (though the query output would still be
correct). Repair, simplifying the code a little, and add a test.
Per report from Richard Guo, though I didn't use their patch. Original
bug seems to have been my fault.
Backpatch back to 9.5 where grouping sets were introduced.
Discussion: https://postgr.es/m/CAN_9JTzyjGcUjiBHxLsgqfk7PkdLGXiM=pwM+=ph2LsWw0WO1A@mail.gmail.com M src/backend/optimizer/plan/planner.c
M src/test/regress/expected/groupingsets.out
M src/test/regress/sql/groupingsets.sql
Fix misleading comment in nodeIndexonlyscan.c.
commit : 0908c5ecf0833b020b0d95183804ebc22bb6ea6c
author : Thomas Munro <[email protected]>
date : Fri, 28 Jun 2019 11:11:26 +1200
committer: Thomas Munro <[email protected]>
date : Fri, 28 Jun 2019 11:11:26 +1200 The stated reason for acquiring predicate locks on heap pages hasn't
existed since commit c01262a8, so fix the comment. Perhaps in a later
release we'll also be able to change the code to use tuple locks.
Back-patch all the way.
Reviewed-by: Ashwin Agrawal
Discussion: https://postgr.es/m/CAEepm%3D2GK3FVdnt5V3d%2Bh9njWipCv_fNL%3DwjxyUhzsF%3D0PcbNg%40mail.gmail.com M src/backend/executor/nodeIndexonlyscan.c
Update reference to sampling algorithm in analyze.c
commit : 30e1b395c9cfee997c9f44cfb27c3c6ec06b5a25
author : Tomas Vondra <[email protected]>
date : Thu, 27 Jun 2019 18:14:25 +0200
committer: Tomas Vondra <[email protected]>
date : Thu, 27 Jun 2019 18:14:25 +0200 Commit 83e176ec1 moved row sampling functions from analyze.c to
utils/misc/sampling.c, but failed to update comment referring to
the sampling algorithm from Jeff Vitter's paper. Correct the
comment by pointing to utils/misc/sampling.c.
Author: Etsuro Fujita
Discussion: https://postgr.es/m/CAPmGK154gp%2BQd%3DcorQOv%2BPmbyVyZBjp_%2Bhb766UJeD1e_ie6XQ%40mail.gmail.com M src/backend/commands/analyze.c
Add support for OpenSSL 1.1.0 and newer versions in MSVC scripts
commit : 5329606693fcd132882c284abbb66bd296a24549
author : Michael Paquier <[email protected]>
date : Wed, 26 Jun 2019 23:05:34 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 26 Jun 2019 23:05:34 +0900 Up to now, the MSVC build scripts are able to support only one fixed
version of OpenSSL, and they lacked logic to detect the version of
OpenSSL a given compilation of Postgres is linking to (currently 1.0.2,
the latest LTS of upstream which will be EOL'd at the end of 2019).
This commit adds more logic to detect the version of OpenSSL used by a
build and makes use of it to add support for compilation with OpenSSL
1.1.0 which requires a new set of compilation flags to work properly.
The supported OpenSSL installers have changed their library layer with
various library renames with the upgrade to 1.1.0, making the logic a
bit more complicated. The scripts are now able to adapt to the new
world order.
Reported-by: Sergey Pashkov
Author: Juan José Santamaría Flecha, Michael Paquier
Reviewed-by: Álvaro Herrera
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.4 M src/tools/msvc/Solution.pm
Don't unset MAKEFLAGS in non-GNU Makefile.
commit : 3a3b361ccbd8563f3b416e5ab5077b73dccd80e8
author : Thomas Munro <[email protected]>
date : Tue, 25 Jun 2019 09:29:53 +1200
committer: Thomas Munro <[email protected]>
date : Tue, 25 Jun 2019 09:29:53 +1200 It's useful to be able to pass down options like -s and -j.
Back-patch to 9.5, like commit a76200de.
Discussion: https://postgr.es/m/CA%2BhUKG%2Be1M8-BbL%3DPqhTp6oO6XPO6%2Bs9WGQMLfbuZ%3DG9CtzyXg%40mail.gmail.com M Makefile
Further fix ALTER COLUMN TYPE's handling of indexes and index constraints.
commit : da1041fc3a2b65a6a36f1b8b91765a46e54e571e
author : Tom Lane <[email protected]>
date : Mon, 24 Jun 2019 16:43:05 -0400
committer: Tom Lane <[email protected]>
date : Mon, 24 Jun 2019 16:43:05 -0400 This patch reverts all the code changes of commit e76de8861, which turns
out to have been seriously misguided. We can't wait till later to compute
the definition string for an index; we must capture that before applying
the data type change for any column it depends on, else ruleutils.c will
deliverr wrong/misleading results. (This fine point was documented
nowhere, of course.)
I'd also managed to forget that ATExecAlterColumnType executes once per
ALTER COLUMN TYPE clause, not once per statement; which resulted in the
code being basically completely broken for any case in which multiple ALTER
COLUMN TYPE clauses are applied to a table having non-constraint indexes
that must be rebuilt. Through very bad luck, none of the existing test
cases nor the ones added by e76de8861 caught that, but of course it was
soon found in the field.
The previous patch also had an implicit assumption that if a constraint's
index had a dependency on a table column, so would the constraint --- but
that isn't actually true, so it didn't fix such cases.
Instead of trying to delete unneeded index dependencies later, do the
is-there-a-constraint lookup immediately on seeing an index dependency,
and switch to remembering the constraint if so. In the unusual case of
multiple column dependencies for a constraint index, this will result in
duplicate constraint lookups, but that's not that horrible compared to all
the other work that happens here. Besides, such cases did not work at all
before, so it's hard to argue that they're performance-critical for anyone.
Per bug #15865 from Keith Fiske. As before, back-patch to all supported
branches.
Discussion: https://postgr.es/m/[email protected] M src/backend/commands/tablecmds.c
M src/test/regress/expected/alter_table.out
M src/test/regress/sql/alter_table.sql
Fix spinlock assembly code for MIPS so it works on MIPS r6.
commit : 9895e3a36a72beec296a319c0462a1aa691ead53
author : Tom Lane <[email protected]>
date : Sat, 22 Jun 2019 20:31:50 -0400
committer: Tom Lane <[email protected]>
date : Sat, 22 Jun 2019 20:31:50 -0400 Original MIPS-I processors didn't have the LL/SC instructions (nor any
other userland synchronization primitive). If the build toolchain
targets that ISA variant by default, as an astonishingly large fraction
of MIPS platforms still do, the assembler won't take LL/SC without
coercion in the form of a ".set mips2" instruction. But we issued that
unconditionally, making it an ISA downgrade for chips later than MIPS2.
That breaks things for the latest MIPS r6 ISA, which encodes these
instructions differently. Adjust the code so we don't change ISA level
if it's >= 2.
Note that this patch doesn't change what happens on an actual MIPS-I
processor: either the kernel will emulate these instructions
transparently, or you'll get a SIGILL failure. That tradeoff seemed
fine in 2002 when this code was added (cf 3cbe6b247), and it's even
more so today when MIPS-I is basically extinct. But let's add a
comment about that.
YunQiang Su (with cosmetic adjustments by me). Back-patch to all
supported branches.
Discussion: https://postgr.es/m/[email protected] M src/include/storage/s_lock.h
Consolidate methods for translating a Perl path to a Windows path.
commit : 186113b049c50a608b575e2597209e9eda99d83c
author : Noah Misch <[email protected]>
date : Fri, 21 Jun 2019 20:34:23 -0700
committer: Noah Misch <[email protected]>
date : Fri, 21 Jun 2019 20:34:23 -0700 This fixes some TAP suites when using msys Perl and a builddir located
in an msys mount point other than "/". For example, builddir=/c/pg
exhibited the problem, since /c/pg falls in mount point "/c".
Back-patch to 9.6, where tests first started to perform such
translations. In back branches, offer both new and old APIs.
Reviewed by Andrew Dunstan.
Discussion: https://postgr.es/m/[email protected] M src/test/perl/PostgresNode.pm
M src/test/perl/TestLib.pm
Remove obsolete comments about sempahores from proc.c.
commit : fe755edc5c7613de062aeb111763ffa8e6b902c4
author : Thomas Munro <[email protected]>
date : Fri, 21 Jun 2019 10:57:07 +1200
committer: Thomas Munro <[email protected]>
date : Fri, 21 Jun 2019 10:57:07 +1200 Commit 6753333f switched from a semaphore-based wait to a latch-based
wait for ProcSleep()/ProcWakeup(), but left behind some stray references
to semaphores.
Back-patch to 9.5.
Reviewed-by: Daniel Gustafsson, Michael Paquier
Discussion: https://postgr.es/m/CA+hUKGLs5H6zhmgTijZ1OaJvC1sG0=AFXc1aHuce32tKiQrdEA@mail.gmail.com M src/backend/storage/lmgr/proc.c
Avoid spurious deadlocks when upgrading a tuple lock
commit : 0ba35c7c9f8e16bdd33893d7236d4fb7fb633b0f
author : Alvaro Herrera <[email protected]>
date : Tue, 18 Jun 2019 18:23:16 -0400
committer: Alvaro Herrera <[email protected]>
date : Tue, 18 Jun 2019 18:23:16 -0400 This puts back reverted commit de87a084c0a5, with some bug fixes.
When two (or more) transactions are waiting for transaction T1 to release a
tuple-level lock, and transaction T1 upgrades its lock to a higher level, a
spurious deadlock can be reported among the waiting transactions when T1
finishes. The simplest example case seems to be:
T1: select id from job where name = 'a' for key share;
Y: select id from job where name = 'a' for update; -- starts waiting for T1
Z: select id from job where name = 'a' for key share;
T1: update job set name = 'b' where id = 1;
Z: update job set name = 'c' where id = 1; -- starts waiting for T1
T1: rollback;
At this point, transaction Y is rolled back on account of a deadlock: Y
holds the heavyweight tuple lock and is waiting for the Xmax to be released,
while Z holds part of the multixact and tries to acquire the heavyweight
lock (per protocol) and goes to sleep; once T1 releases its part of the
multixact, Z is awakened only to be put back to sleep on the heavyweight
lock that Y is holding while sleeping. Kaboom.
This can be avoided by having Z skip the heavyweight lock acquisition. As
far as I can see, the biggest downside is that if there are multiple Z
transactions, the order in which they resume after T1 finishes is not
guaranteed.
Backpatch to 9.6. The patch applies cleanly on 9.5, but the new tests don't
work there (because isolationtester is not smart enough), so I'm not going
to risk it.
Author: Oleksii Kliukin
Discussion: https://postgr.es/m/[email protected]
Discussion: https://postgr.es/m/[email protected] M src/backend/access/heap/README.tuplock
M src/backend/access/heap/heapam.c
A src/test/isolation/expected/tuplelock-upgrade-no-deadlock.out
M src/test/isolation/isolation_schedule
A src/test/isolation/specs/tuplelock-upgrade-no-deadlock.spec