Stamp 10.10.
commit : 2fbecb66c45eccb8922c371084ae4f0b3a72a86b
author : Tom Lane <[email protected]>
date : Mon, 5 Aug 2019 17:16:54 -0400
committer: Tom Lane <[email protected]>
date : Mon, 5 Aug 2019 17:16:54 -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 : f61bc0048b6b3a9bac7afd469cb6811d29d29d5d
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-10.sgml
Require the schema qualification in pg_temp.type_name(arg).
commit : 2062007cbf7008de383c8f2f4a9ad466ea243acf
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 : 5e32ae9d05d3b7e946cecc99bfa0c835dd108787
author : Peter Eisentraut <[email protected]>
date : Mon, 5 Aug 2019 15:44:33 +0200
committer: Peter Eisentraut <[email protected]>
date : Mon, 5 Aug 2019 15:44:33 +0200 Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git
Source-Git-Hash: 361643d9eb7a2585dfcfc73838fee5a9940db6eb M src/backend/po/de.po
M src/backend/po/ja.po
M src/backend/po/ru.po
M src/backend/po/sv.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/pg_rewind/po/ru.po
M src/bin/pg_upgrade/po/de.po
M src/bin/psql/po/ru.po
M src/bin/scripts/po/ru.po
M src/interfaces/libpq/po/de.po
M src/interfaces/libpq/po/ru.po
M src/interfaces/libpq/po/sv.po
Fix tab completion for ALTER LANGUAGE in psql
commit : e733adc51fbb7788e8840c05322b5c2c110fcf9b
author : Michael Paquier <[email protected]>
date : Mon, 5 Aug 2019 14:30:27 +0900
committer: Michael Paquier <[email protected]>
date : Mon, 5 Aug 2019 14:30:27 +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 : 670f2a43c2b980fd6dd7495ace10190b9efed227
author : Tom Lane <[email protected]>
date : Sun, 4 Aug 2019 17:08:41 -0400
committer: Tom Lane <[email protected]>
date : Sun, 4 Aug 2019 17:08:41 -0400 M doc/src/sgml/release-10.sgml
Fix handling of previous password hooks in passwordcheck
commit : cb007441789dc19d40b4ae8902e0108b75811f00
author : Michael Paquier <[email protected]>
date : Thu, 1 Aug 2019 09:38:14 +0900
committer: Michael Paquier <[email protected]>
date : Thu, 1 Aug 2019 09:38:14 +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 : 7615afa48e7ca50eb73eaf8772736923c7d810f2
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 : 35fc44b58c10ab9cb581ff0b5b51b7653fd7523f
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
Don't build extended statistics on inheritance trees
commit : 859b3003de87645b62ee07ef245d6c1f1cd0cedb
author : Tomas Vondra <[email protected]>
date : Tue, 30 Jul 2019 19:17:12 +0200
committer: Tomas Vondra <[email protected]>
date : Tue, 30 Jul 2019 19:17:12 +0200 When performing ANALYZE on inheritance trees, we collect two samples for
each relation - one for the relation alone, and one for the inheritance
subtree (relation and its child relations). And then we build statistics
on each sample, so for each relation we get two sets of statistics.
For regular (per-column) statistics this works fine, because the catalog
includes a flag differentiating statistics built from those two samples.
But we don't have such flag in the extended statistics catalogs, and we
ended up updating the same row twice, triggering this error:
ERROR: tuple already updated by self
The simplest solution is to disable extended statistics on inheritance
trees, which is what this commit is doing. In the future we may need to
do something similar to per-column statistics, but that requires adding a
flag to the catalog - and that's not backpatchable. Moreover, the current
selectivity estimation code only works with individual relations, so
building statistics on inheritance trees would be pointless anyway.
Author: Tomas Vondra
Backpatch-to: 10-
Discussion: https://postgr.es/m/[email protected]
Reported-by: Justin Pryzby M src/backend/commands/analyze.c
M src/test/regress/expected/stats_ext.out
M src/test/regress/sql/stats_ext.sql
Fix busted logic for parallel lock grouping in TopoSort().
commit : af41ab50fdc592608a12912def17f4628ea52e70
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 : e9ecf736e121758baf67cee6be9ee7ed285ca2d3
author : Michael Paquier <[email protected]>
date : Sun, 28 Jul 2019 22:02:39 +0900
committer: Michael Paquier <[email protected]>
date : Sun, 28 Jul 2019 22:02:39 +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 : 52608f3416075dc57a8e12ff0c3e6af03549c7d5
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
Fix possible lockup in pgbench with -R.
commit : 46c193213adb4cbcdd0f8198b361de27d0ca13fe
author : Tom Lane <[email protected]>
date : Fri, 26 Jul 2019 15:17:03 -0400
committer: Tom Lane <[email protected]>
date : Fri, 26 Jul 2019 15:17:03 -0400 pgbench would sometimes get stuck waiting forever after its last
client thread terminated, due to failing to check for there being
nothing more to wait for.
Bug introduced during refactoring in v10 (I didn't bother to try to
assign blame to a specific commit). It's already repaired in
HEAD/v12 thanks to commit 3bac77c48, but v10 and v11 need this fix.
Fabien Coelho, per report from Tomas Vondra; reviewed by
Yoshikazu Imai
Discussion: https://postgr.es/m/[email protected] M src/bin/pgbench/pgbench.c
Tweak our special-case logic for the IANA "Factory" timezone.
commit : 55862b2e93030b6720123f888217a557532dd894
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 : ae9b91be79ea2fc92f55e54f8bdeb6343d8fad69
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 : fa854112fc3d5fae1da071bd647eb777eb584c2e
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 : ed304d1e26552c5fdc2fdb0dcac9335f7f33e86c
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 : cb65b454f87b958a603bfb29cac03ad363d3344d
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 : 165f4eecfeb71581c05f371f72eb99742cbae18c
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 : 5c3d47287fd7c76aa376d035695bffde6d59a7c8
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 : 183cd8c67a3734a8f8b87b7e2b81d0b89f933e01
author : Michael Paquier <[email protected]>
date : Thu, 25 Jul 2019 07:55:37 +0900
committer: Michael Paquier <[email protected]>
date : Thu, 25 Jul 2019 07:55:37 +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 infelicities in describeOneTableDetails' partitioned-table handling.
commit : 3808cf21f634ab0b6d6ec680684014a1fb89134f
author : Tom Lane <[email protected]>
date : Wed, 24 Jul 2019 18:14:27 -0400
committer: Tom Lane <[email protected]>
date : Wed, 24 Jul 2019 18:14:27 -0400 describeOneTableDetails issued a partition-constraint-fetching query
for every table, even ones it knows perfectly well are not partitions.
To add insult to injury, it then proceeded to leak the empty PGresult
if the table wasn't a partition. Doing that a lot of times might
amount to a meaningful leak, so this seems like a back-patchable bug.
Fix that, and also fix a related PGresult leak in the partition-parent
case (though that leak would occur only if we got no row, which is
unexpected).
Minor code beautification too, to make this code look more like the
pre-existing code around it.
Back-patch the whole change into v12. However, the fact that we already
know whether the table is a partition dates only to commit 1af25ca0c;
back-patching the relevant changes from that is probably more churn
than is justified in released branches. Hence, in v11 and v10, just
do the minimum to fix the PGresult leaks.
Noted while messing around with adjacent code for yesterday's \d
improvements. M src/bin/psql/describe.c
Fix build of documentation
commit : ba7359d5fed01ec20560fba98f57a67b041614b9
author : Michael Paquier <[email protected]>
date : Wed, 24 Jul 2019 16:02:23 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 24 Jul 2019 16:02:23 +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_receivewal.sgml
Doc: Clarify interactions of pg_receivewal with remote_apply
commit : 1c423463e4b91ec784b935895d77b6ceb3301141
author : Michael Paquier <[email protected]>
date : Wed, 24 Jul 2019 11:26:33 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 24 Jul 2019 11:26:33 +0900 Using pg_receivewal with synchronous_commit = remote_apply set in the
backend is incompatible if pg_receivewal is a synchronous standby as it
never applies WAL, so document this problem and solutions to it.
Backpatch to 9.6, where remote_apply has been added.
Author: Robert Haas, Jesper Pedersen
Reviewed-by: Laurenz Albe, Álvaro Herrera, Michael Paquier
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 9.6 M doc/src/sgml/ref/pg_receivewal.sgml
Improve stability of TAP test for synchronous replication
commit : 46fb7ff65ec29f7aab2e479ab43a180d67a267ed
author : Michael Paquier <[email protected]>
date : Wed, 24 Jul 2019 10:54:32 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 24 Jul 2019 10:54:32 +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 : 7ac7bf50cc9a7ecdeea683fd92e1a0e0c9e7cf19
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
Install dependencies to prevent dropping partition key columns.
commit : 0e1deaa4c4247ad89d0d3d4226a2eb85a894c778
author : Tom Lane <[email protected]>
date : Mon, 22 Jul 2019 14:55:23 -0400
committer: Tom Lane <[email protected]>
date : Mon, 22 Jul 2019 14:55:23 -0400 The logic in ATExecDropColumn that rejects dropping partition key
columns is quite an inadequate defense, because it doesn't execute
in cases where a column needs to be dropped due to cascade from
something that only the column, not the whole partitioned table,
depends on. That leaves us with a badly broken partitioned table;
even an attempt to load its relcache entry will fail.
We really need to have explicit pg_depend entries that show that the
column can't be dropped without dropping the whole table. Hence,
add those entries. In v12 and HEAD, bump catversion to ensure that
partitioned tables will have such entries. We can't do that in
released branches of course, so in v10 and v11 this patch affords
protection only to partitioned tables created after the patch is
installed. Given the lack of field complaints (this bug was found
by fuzz-testing not by end users), that's probably good enough.
In passing, fix ATExecDropColumn and ATPrepAlterColumnType
messages to be more specific about which partition key column
they're complaining about.
Per report from Manuel Rigger. Back-patch to v10 where partitioned
tables were added.
Discussion: https://postgr.es/m/CA+u7OA4JKCPFrdrAbOs7XBiCyD61XJxeNav4LefkSmBLQ-Vobg@mail.gmail.com
Discussion: https://postgr.es/m/[email protected] M src/backend/catalog/dependency.c
M src/backend/catalog/heap.c
M src/backend/commands/tablecmds.c
M src/bin/pg_dump/pg_dump_sort.c
M src/include/catalog/dependency.h
M src/test/regress/expected/alter_table.out
M src/test/regress/expected/create_table.out
M src/test/regress/sql/create_table.sql
Silence compiler warning, hopefully.
commit : 8a4fa297a5ddaa41390f76f04556556399cf9a29
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 : b0a7e0f07fadba9542a711a4cbafc244c19d493b
author : Jeff Davis <[email protected]>
date : Thu, 18 Jul 2019 16:49:25 -0700
committer: Jeff Davis <[email protected]>
date : Thu, 18 Jul 2019 16:49: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 : 955089d4d74d0dbaaa6c1e3a4652e96b6d1c2f54
author : Jeff Davis <[email protected]>
date : Thu, 18 Jul 2019 16:49:10 -0700
committer: Jeff Davis <[email protected]>
date : Thu, 18 Jul 2019 16:49:10 -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 : 53256e892e6bf747d4ad0250b6a803a294d3bc0e
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 : ccc323b57fb6b385d110d50c5ee056ab0024eb53
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 : 583025c3c7e61448d1e6facca770a2171666428c
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 : f68060cadb390a3653221a99bdc19be59ca58787
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 : 15f2f2759ecd0c2cf2a72644f3b1407478876968
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 : 4fea3434939dfb29a16bf61baca8020e5142ccda
author : Michael Paquier <[email protected]>
date : Wed, 10 Jul 2019 15:15:11 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 10 Jul 2019 15:15:11 +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
Pass QueryEnvironment down to EvalPlanQual's EState.
commit : 72b526779a9320e2dd8ff63237fbaf2e933b5c34
author : Thomas Munro <[email protected]>
date : Wed, 10 Jul 2019 10:16:02 +1200
committer: Thomas Munro <[email protected]>
date : Wed, 10 Jul 2019 10:16:02 +1200 Otherwise the executor can't see trigger transition tables during
EPQ evaluation. Fixes bug #15900 and almost certainly also #15720.
Back-patch to 10, where trigger transition tables landed.
Author: Alex Aktsipetrov
Reviewed-by: Thomas Munro, Tom Lane
Discussion: https://postgr.es/m/15900-bc482754fe8d7415%40postgresql.org
Discussion: https://postgr.es/m/15720-38c2b29e5d720187%40postgresql.org M src/backend/executor/execMain.c
doc: Clarify logical replication documentation
commit : a5407d1bd6286c0f932514b8dc58f472981e0243
author : Peter Eisentraut <[email protected]>
date : Mon, 8 Jul 2019 14:28:42 +0200
committer: Peter Eisentraut <[email protected]>
date : Mon, 8 Jul 2019 14:28:42 +0200 Document that the data types of replicated tables do not need to
match. The documentation previously claimed that they had to match.
Author: Robert Treat <[email protected]>
Discussion: https://www.postgresql.org/message-id/flat/CAJSLCQ13==D8Ka2YLyctTm0Y+8MhGYcX_zj7fU0rqRzhcV++3w@mail.gmail.com M doc/src/sgml/logical-replication.sgml
Don't remove surplus columns from GROUP BY for inheritance parents
commit : 232019b79229db7a438f00f358d86659fbd6fcb9
author : David Rowley <[email protected]>
date : Wed, 3 Jul 2019 23:46:06 +1200
committer: David Rowley <[email protected]>
date : Wed, 3 Jul 2019 23:46:06 +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 : 0ce8e49b224300fe895f5cda6b8e45d80bbdf860
author : Michael Paquier <[email protected]>
date : Wed, 3 Jul 2019 08:58:04 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 3 Jul 2019 08:58:04 +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 : 90434e6f2cf9fb629069b1b3017ea1a2c1ab07eb
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 : cd9d48969d944c3558a77745db389e8b68b46c4b
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 : a1637caee9c77e30aaf4afb5c51e15cb67c4f3e3
author : Andrew Gierth <[email protected]>
date : Sun, 30 Jun 2019 23:49:25 +0100
committer: Andrew Gierth <[email protected]>
date : Sun, 30 Jun 2019 23:49:25 +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 : 69da8c1e69efd3a5b1b0f1d9bd8b7b79a696fbc8
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 : 0161e522cbb536d8978ca8e5b5341b16805cc6b4
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 : a559805597d5e860796d6c9430134b8e41022ef8
author : Michael Paquier <[email protected]>
date : Wed, 26 Jun 2019 23:05:06 +0900
committer: Michael Paquier <[email protected]>
date : Wed, 26 Jun 2019 23:05:06 +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
Follow the rule that regression-test-created roles are named "regress_xxx".
commit : 80931442c9c93b6c94d56808697648e44f0625ee
author : Tom Lane <[email protected]>
date : Tue, 25 Jun 2019 23:19:31 -0400
committer: Tom Lane <[email protected]>
date : Tue, 25 Jun 2019 23:19:31 -0400 contrib/amcheck didn't get the memo either. M contrib/amcheck/expected/check_btree.out
M contrib/amcheck/sql/check_btree.sql
Fix thinkos in LookupFuncName() for function name lookups
commit : 131e545ac304a3f5c4f8575131f4b338232cac0d
author : Michael Paquier <[email protected]>
date : Tue, 25 Jun 2019 11:16:04 +0900
committer: Michael Paquier <[email protected]>
date : Tue, 25 Jun 2019 11:16:04 +0900 This could trigger valgrind failures when doing ambiguous function name
lookups when no arguments are provided by the caller. The problem has
been introduced in aefeb68, so backpatch to v10. HEAD is fine thanks to
the refactoring done in bfb456c1.
Reported-by: Alexander Lakhin
Author: Alexander Lakhin, Michael Paquier
Discussion: https://postgr.es/m/[email protected]
Backpatch-through: 10 M src/backend/parser/parse_func.c
Don't unset MAKEFLAGS in non-GNU Makefile.
commit : 956611e4c480a2b7edeb2f1581e99f19f1983ca5
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 : cb8962ce8eb4bc8377d88424069794ad62080d4d
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 : 05399b14889e32f2714b428836c841b08d1d5258
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 : 6121ba9d18efa30d09db80708c1e222c81daff97
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 : df098c371b882eeafa168501f0d20330c9a186fc
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 : 0772d8a00eb88b50ac81f379955d30660cecdeeb
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