commit : 246893dce8ebea90ef083ab801da4d1f474e01ad author : Tom Lane <email@example.com> date : Mon, 5 Aug 2019 17:22:47 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Mon, 5 Aug 2019 17:22:47 -0400
Last-minute updates for release notes.
commit : 4908df4a609aa1f2b3def968fe5b94a74cfde214 author : Tom Lane <email@example.com> date : Mon, 5 Aug 2019 11:49:14 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Mon, 5 Aug 2019 11:49:14 -0400
Security: CVE-2019-10208, CVE-2019-10209
Require the schema qualification in pg_temp.type_name(arg).
commit : 86737438b2449832371ca8295f8af48630d8481e author : Noah Misch <email@example.com> date : Mon, 5 Aug 2019 07:48:41 -0700 committer: Noah Misch <firstname.lastname@example.org> 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
commit : bdba067e19a8ee5d9f68b5621b2a8447ed875ad0 author : Peter Eisentraut <email@example.com> date : Mon, 5 Aug 2019 15:32:33 +0200 committer: Peter Eisentraut <firstname.lastname@example.org> date : Mon, 5 Aug 2019 15:32:33 +0200
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 1e9fc1877f208ca17b4ad5c62cd22590b64c449c
Release notes for 11.5, 10.10, 9.6.15, 9.5.19, 9.4.24.
commit : 83c8b61771a49485a2ecec80418c8cc2f82b6457 author : Tom Lane <email@example.com> date : Sun, 4 Aug 2019 17:08:42 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Sun, 4 Aug 2019 17:08:42 -0400
Fix handling of previous password hooks in passwordcheck
commit : eea28a3cb36951ee439288d8e400621ec301484f author : Michael Paquier <email@example.com> date : Thu, 1 Aug 2019 09:38:29 +0900 committer: Michael Paquier <firstname.lastname@example.org> date : Thu, 1 Aug 2019 09:38:29 +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://email@example.com Backpatch-through: 9.4
Fix pg_dump's handling of dependencies for custom opclasses.
commit : 4e10b6f8235500b99ecd0a3ca7602acdf0034c8a author : Tom Lane <firstname.lastname@example.org> date : Wed, 31 Jul 2019 15:42:50 -0400 committer: Tom Lane <email@example.com> 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://firstname.lastname@example.org
Doc: Fix event trigger firing table
commit : 5f2a94a38d24afb2cbf79b048fdd6f5d319b9f49 author : Michael Paquier <email@example.com> date : Sun, 28 Jul 2019 22:02:56 +0900 committer: Michael Paquier <firstname.lastname@example.org> date : Sun, 28 Jul 2019 22:02:56 +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://email@example.com Backpatch-through: 9.4
Tweak our special-case logic for the IANA "Factory" timezone.
commit : e49132e633b5af7f26c059ed7d96f62ced683127 author : Tom Lane <firstname.lastname@example.org> date : Fri, 26 Jul 2019 13:07:08 -0400 committer: Tom Lane <email@example.com> 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://firstname.lastname@example.org
Avoid choosing "localtime" or "posixrules" as TimeZone during initdb.
commit : 6c4ffab76320d492cfd262efdef1776c50787176 author : Tom Lane <email@example.com> date : Fri, 26 Jul 2019 12:45:32 -0400 committer: Tom Lane <firstname.lastname@example.org> 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://email@example.com
Fix loss of fractional digits for large values in cash_numeric().
commit : 81b29c87114cdcc2ff1a9247124c59d94d20a237 author : Tom Lane <firstname.lastname@example.org> date : Fri, 26 Jul 2019 11:59:00 -0400 committer: Tom Lane <email@example.com> 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://firstname.lastname@example.org
Fix syntax error in commit 20e99cddd.
commit : 7ea91ae1980d52655837e7e3e563eb75eecbe29d author : Tom Lane <email@example.com> date : Thu, 25 Jul 2019 14:42:02 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Thu, 25 Jul 2019 14:42:02 -0400
Fix failures to ignore \r when reading Windows-style newlines.
commit : 8c52b77ddea778859e91e58397077d762016f632 author : Tom Lane <email@example.com> date : Thu, 25 Jul 2019 12:10:55 -0400 committer: Tom Lane <firstname.lastname@example.org> 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://email@example.com
Honor MSVC WindowsSDKVersion if set
commit : 53fd0f04b87bf37288f65b5944ac30c64296a745 author : Andrew Dunstan <firstname.lastname@example.org> date : Thu, 25 Jul 2019 11:24:23 -0400 committer: Andrew Dunstan <email@example.com> 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.
Fix contrib/sepgsql test policy to work with latest SELinux releases.
commit : 0e259d4bc78956c173c9a81c03713e17b6513738 author : Tom Lane <firstname.lastname@example.org> date : Thu, 25 Jul 2019 11:02:43 -0400 committer: Tom Lane <email@example.com> 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://firstname.lastname@example.org
Make pg_upgrade's test.sh less chatty.
commit : 19f9a5aed9a734ca0904df039c777bba569e0d2c author : Tom Lane <email@example.com> date : Mon, 22 Jul 2019 17:14:22 -0400 committer: Tom Lane <firstname.lastname@example.org> 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://email@example.com Discussion: https://postgr.es/m/20190722193459.GA14241@alvherre.pgsql
Silence compiler warning, hopefully.
commit : 847561c1d5e2197042565c9d7966e7b50bb67593 author : Tom Lane <firstname.lastname@example.org> date : Fri, 19 Jul 2019 14:48:57 -0400 committer: Tom Lane <email@example.com> date : Fri, 19 Jul 2019 14:48:57 -0400
Absorb commit e5e04c962a5d12eebbf867ca25905b3ccc34cbe0 from upstream IANA code, in hopes of silencing warnings from MSVC about negating a bool value. Discussion: https://postgr.es/m/20190719035347.GJ1859@paquier.xyz
Fix error in commit e6feef57.
commit : 812623b69eac3535bcf422e6aea335d6f7753fec author : Jeff Davis <firstname.lastname@example.org> date : Thu, 18 Jul 2019 17:01:58 -0700 committer: Jeff Davis <email@example.com> date : Thu, 18 Jul 2019 17:01:58 -0700
I was careless passing a datum directly to DATE_NOT_FINITE without calling DatumGetDateADT() first. Backpatch-through: 9.4
Fix daterange canonicalization for +/- infinity.
commit : 2be355498eafaddc1c274f05884e1ed79b671655 author : Jeff Davis <firstname.lastname@example.org> date : Thu, 18 Jul 2019 17:01:44 -0700 committer: Jeff Davis <email@example.com> date : Thu, 18 Jul 2019 17:01:44 -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
Update time zone data files to tzdata release 2019b.
commit : 8474656d993497c42caa68342c39d608f8854f8d author : Tom Lane <firstname.lastname@example.org> date : Wed, 17 Jul 2019 19:15:21 -0400 committer: Tom Lane <email@example.com> date : Wed, 17 Jul 2019 19:15:21 -0400
Brazil no longer observes DST. Historical corrections for Palestine, Hong Kong, and Italy.
Sync our copy of the timezone library with IANA release tzcode2019b.
commit : 6db29a8fc2868a1b2b7ea3192dd36f111673458b author : Tom Lane <firstname.lastname@example.org> date : Wed, 17 Jul 2019 18:26:24 -0400 committer: Tom Lane <email@example.com> 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.
Fix thinko in construction of old_conpfeqop list.
commit : 67bd6adcb64b182137142f6fd501024a5b971147 author : Tom Lane <firstname.lastname@example.org> date : Tue, 16 Jul 2019 18:17:47 -0400 committer: Tom Lane <email@example.com> 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.
doc: mention pg_reload_conf() for reloading the config file
commit : 5dbe666ff89cf48ce4fc70c731a1b2ee7336faaf author : Bruce Momjian <firstname.lastname@example.org> date : Mon, 15 Jul 2019 20:57:24 -0400 committer: Bruce Momjian <email@example.com> date : Mon, 15 Jul 2019 20:57:24 -0400
Reported-by: Ian Barwick Discussion: https://firstname.lastname@example.org Backpatch-through: 9.4
Fix variable initialization when using buffering build with GiST
commit : 7b60468fa14ac8b65ba91f2dc3c2df11361d4be3 author : Michael Paquier <email@example.com> date : Wed, 10 Jul 2019 15:15:29 +0900 committer: Michael Paquier <firstname.lastname@example.org> date : Wed, 10 Jul 2019 15:15:29 +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://email@example.com Backpatch-through: 9.4
Add support for Visual Studio 2019 in build scripts
commit : d49c127d90f94579a13106d4e7b198d04e5eea88 author : Michael Paquier <firstname.lastname@example.org> date : Wed, 3 Jul 2019 08:58:34 +0900 committer: Michael Paquier <email@example.com> date : Wed, 3 Jul 2019 08:58:34 +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
Fix misleading comment in nodeIndexonlyscan.c.
commit : 706cb9bf4f43eb2b9e8ad8fd6e0d4190575fe069 author : Thomas Munro <firstname.lastname@example.org> date : Fri, 28 Jun 2019 11:11:26 +1200 committer: Thomas Munro <email@example.com> 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
Update reference to sampling algorithm in analyze.c
commit : e46cd427880eb064e28ab5bfa3123ba820eeccd2 author : Tomas Vondra <firstname.lastname@example.org> date : Thu, 27 Jun 2019 18:14:25 +0200 committer: Tomas Vondra <email@example.com> 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
Add support for OpenSSL 1.1.0 and newer versions in MSVC scripts
commit : 05b2758c39e20068a450b2d8044ce9672259c55b author : Michael Paquier <firstname.lastname@example.org> date : Wed, 26 Jun 2019 23:06:14 +0900 committer: Michael Paquier <email@example.com> date : Wed, 26 Jun 2019 23:06:14 +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://firstname.lastname@example.org Backpatch-through: 9.4
Further fix ALTER COLUMN TYPE's handling of indexes and index constraints.
commit : ddfb1b2eeaec25928f5b326e36092e06ce627038 author : Tom Lane <email@example.com> date : Mon, 24 Jun 2019 16:43:05 -0400 committer: Tom Lane <firstname.lastname@example.org> 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://email@example.com
Fix spinlock assembly code for MIPS so it works on MIPS r6.
commit : 2854e2ab6806cc705d7ff92dd1f60f1cd70da98c author : Tom Lane <firstname.lastname@example.org> date : Sat, 22 Jun 2019 20:31:50 -0400 committer: Tom Lane <email@example.com> 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://firstname.lastname@example.org