Disallow changing an inherited column's type if not all parents changed.
commit : 451432214f1a9c59e59dbbcdd91e92bb69e6cd03 author : Tom Lane <firstname.lastname@example.org> date : Sun, 18 Aug 2019 17:11:58 -0400 committer: Tom Lane <email@example.com> date : Sun, 18 Aug 2019 17:11:58 -0400
If a table inherits from multiple unrelated parents, we must disallow changing the type of a column inherited from multiple such parents, else it would be out of step with the other parents. However, it's possible for the column to ultimately be inherited from just one common ancestor, in which case a change starting from that ancestor should still be allowed. (I would not be excited about preserving that option, were it not that we have regression test cases exercising it already ...) It's slightly annoying that this patch looks different from the logic with the same end goal in renameatt(), and more annoying that it requires an extra syscache lookup to make the test. However, the recursion logic is quite different in the two functions, and a back-patched bug fix is no place to be trying to unify them. Per report from Manuel Rigger. Back-patch to 9.5. The bug exists in 9.4 too (and doubtless much further back); but the way the recursion is done in 9.4 is a good bit different, so that substantial refactoring would be needed to fix it in 9.4. I'm disinclined to do that, or risk introducing new bugs, for a bug that has escaped notice for this long. Discussion: https://postgr.es/m/CA+u7OA4qogDv9rz1HAb-ADxttXYPqQdUdPY_yd4kCzywNxRQXA@mail.gmail.com
Prevent possible double-free when update trigger returns old tuple.
commit : 60886965a271242c19e40483c82b41ff726ca24e author : Tom Lane <firstname.lastname@example.org> date : Thu, 15 Aug 2019 20:04:19 -0400 committer: Tom Lane <email@example.com> date : Thu, 15 Aug 2019 20:04:19 -0400
This is a variant of the problem fixed in commit 25b692568, which unfortunately we failed to detect at the time. If an update trigger returns the "old" tuple, as it's entitled to do, then a subsequent iteration of the loop in ExecBRUpdateTriggers would have "oldtuple" equal to "trigtuple" and would fail to notice that it shouldn't free that. In addition to fixing the code, extend the test case added by 25b692568 so that it covers multiple-trigger-iterations cases. This problem does not manifest in v12/HEAD, as a result of the relevant code having been largely rewritten for slotification. However, include the test case into v12/HEAD anyway, since this is clearly an area that someone could break again in future. Per report from Piotr Gabriel Kosinski. Back-patch into all supported branches, since the bug seems quite old. Diagnosis and code fix by Thomas Munro, test case by me. Discussion: https://postgr.es/m/CAFMLSdP0rd7LqC3j-H6Fh51FYSt5A10DDh-3=W4PPc4LLUQ8YQ@mail.gmail.com
Doc: improve documentation about postgresql.auto.conf.
commit : e3ddb112f245041565aa102e20234799e366caab author : Tom Lane <firstname.lastname@example.org> date : Thu, 15 Aug 2019 11:14:26 -0400 committer: Tom Lane <email@example.com> date : Thu, 15 Aug 2019 11:14:26 -0400
Clarify what external tools can do to this file, and add a bit of detail about what ALTER SYSTEM itself does. Discussion: https://firstname.lastname@example.org
Fix ALTER SYSTEM to cope with duplicate entries in postgresql.auto.conf.
commit : f8c9a08520eea2ea7f0197b878515d99861d6221 author : Tom Lane <email@example.com> date : Wed, 14 Aug 2019 15:09:20 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Wed, 14 Aug 2019 15:09:20 -0400
ALTER SYSTEM itself normally won't make duplicate entries (although up till this patch, it was possible to confuse it by writing case variants of a GUC's name). However, if some external tool has appended entries to the file, that could result in duplicate entries for a single GUC name. In such a situation, ALTER SYSTEM did exactly the wrong thing, because it replaced or removed only the first matching entry, leaving the later one(s) still there and hence still determining the active value. This patch fixes that by making ALTER SYSTEM sweep through the file and remove all matching entries, then (if not ALTER SYSTEM RESET) append the new setting to the end. This means entries will be in order of last setting rather than first setting, but that shouldn't hurt anything. Also, make the comparisons case-insensitive so that the right things happen if you do, say, ALTER SYSTEM SET "TimeZone" = 'whatever'. This has been broken since ALTER SYSTEM was invented, so back-patch to all supported branches. Ian Barwick, with minor mods by me Discussion: https://email@example.com
Un-break pg_dump for pre-8.3 source servers.
commit : f2bdfebb962d117c51b60dcb63de1adcc9ee0380 author : Tom Lane <firstname.lastname@example.org> date : Tue, 13 Aug 2019 16:57:58 -0400 committer: Tom Lane <email@example.com> date : Tue, 13 Aug 2019 16:57:58 -0400
Commit 07b39083c inserted an unconditional reference to pg_opfamily, which of course fails on servers predating that catalog. Fortunately, the case it's trying to solve can't occur on such old servers (AFAIK). Hence, just skip the additional code when the source predates 8.3. Per bug #15955 from sly. Back-patch to all supported branches, like the previous patch. Discussion: https://firstname.lastname@example.org
Fix random regression failure in test case "temp"
commit : fc8c6ae5fdebb8dc39b3d001aa332b80e0945fc2 author : Michael Paquier <email@example.com> date : Tue, 13 Aug 2019 10:56:07 +0900 committer: Michael Paquier <firstname.lastname@example.org> date : Tue, 13 Aug 2019 10:56:07 +0900
This test case could fail because of an incorrect result ordering when looking up at pg_class entries. This commit adds an ORDER BY to the culprit query. The cause of the failure was likely caused by a plan switch. By default, the planner would likely choose an index-only scan or an index scan, but even a small change in the startup cost could have caused a bitmap heap scan to be chosen, causing the failure. While on it, switch some filtering quals to a regular expression as per an idea of Tom Lane. As previously shaped, the quals would have selected any relations whose name begins with "temp". And that could cause failures if another test running in parallel began to use similar relation names. Per report from buildfarm member anole, though the failure was very rare. This test has been introduced by 319a810, so backpatch down to v10. Discussion: https://postgr.es/m/20190807132422.GC15695@paquier.xyz Backpatch-through: 10
amcheck: Skip unlogged relations during recovery.
commit : f8d2cdc12c9407f26b7872bfb0153a899a5ee299 author : Peter Geoghegan <email@example.com> date : Mon, 12 Aug 2019 15:21:27 -0700 committer: Peter Geoghegan <firstname.lastname@example.org> date : Mon, 12 Aug 2019 15:21:27 -0700
contrib/amcheck failed to consider the possibility that unlogged relations will not have any main relation fork files when running in hot standby mode. This led to low-level "can't happen" errors that complain about the absence of a relfilenode file. To fix, simply skip verification of unlogged index relations during recovery. In passing, add a direct check for the presence of a main fork just before verification proper begins, so that we cleanly verify the presence of the main relation fork file. Author: Andrey Borodin, Peter Geoghegan Reported-By: Andrey Borodin Diagnosed-By: Andrey Borodin Discussion: https://postgr.es/m/DA9B33AC-53CB-4643-96D4-7A0BBC037FA1@yandex-team.ru Backpatch: 10-, where amcheck was introduced.
Fix compiler warning
commit : 333a186dc52e32ce250c9d62d9dbaecbd359d651 author : Peter Eisentraut <email@example.com> date : Mon, 12 Aug 2019 21:20:14 +0200 committer: Peter Eisentraut <firstname.lastname@example.org> date : Mon, 12 Aug 2019 21:20:14 +0200
With some newer gcc versions (8 and 9) you get a -Wformat-overflow warning here. In PG11 and later this was already fixed. Since it's trivial, backport it to get the older branches building without warnings.
Fix planner's test for case-foldable characters in ILIKE with ICU.
commit : 886cf85b52cfdd84c0ff9b24193c7e0e0035b1c7 author : Tom Lane <email@example.com> date : Mon, 12 Aug 2019 13:15:48 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Mon, 12 Aug 2019 13:15:48 -0400
As coded, the ICU-collation path in pattern_char_isalpha() failed to consider regular ASCII letters to be case-varying. This led to like_fixed_prefix treating too much of an ILIKE pattern as being a fixed prefix, so that indexscans derived from an ILIKE clause might miss entries that they should find. Per bug #15892 from James Inform. This is an oversight in the original ICU patch (commit eccfef81e), so back-patch to v10 where that came in. Discussion: https://email@example.com
Doc: document permissions required for ANALYZE.
commit : b3670f48d8bc83a334a97e7270c5d59f694c4126 author : Tom Lane <firstname.lastname@example.org> date : Wed, 7 Aug 2019 18:09:28 -0400 committer: Tom Lane <email@example.com> date : Wed, 7 Aug 2019 18:09:28 -0400
VACUUM's reference page had this text, but ANALYZE's didn't. That's a clear oversight given that section 5.7 explicitly delegates the responsibility to define permissions requirements to the individual commands' man pages. Per gripe from Isaac Morland. Back-patch to all supported branches. Discussion: https://postgr.es/m/CAMsGm5fp3oBUs-2iRfii0iEO=fZuJALVyM2zJLhNTjG34gpAVQ@mail.gmail.com
Fix typo in comment.
commit : dcebb3e9c7cf7836779a82fcc202af9b5266a893 author : Etsuro Fujita <firstname.lastname@example.org> date : Wed, 7 Aug 2019 19:05:20 +0900 committer: Etsuro Fujita <email@example.com> date : Wed, 7 Aug 2019 19:05:20 +0900
Fix predicate-locking of HOT updated rows.
commit : 65468cc705ea8a329f175de7eed44163ce532482 author : Heikki Linnakangas <firstname.lastname@example.org> date : Wed, 7 Aug 2019 12:40:49 +0300 committer: Heikki Linnakangas <email@example.com> date : Wed, 7 Aug 2019 12:40:49 +0300
In serializable mode, heap_hot_search_buffer() incorrectly acquired a predicate lock on the root tuple, not the returned tuple that satisfied the visibility checks. As explained in README-SSI, the predicate lock does not need to be copied or extended to other tuple versions, but for that to work, the correct, visible, tuple version must be locked in the first place. The original SSI commit had this bug in it, but it was fixed back in 2013, in commit 81fbbfe335. But unfortunately, it was reintroduced a few months later in commit b89e151054. Wising up from that, add a regression test to cover this, so that it doesn't get reintroduced again. Also, move the code that sets 't_self', so that it happens at the same time that the other HeapTuple fields are set, to make it more clear that all the code in the loop operate on the "current" tuple in the chain, not the root tuple. Bug spotted by Andres Freund, analysis and original fix by Thomas Munro, test case and some additional changes to the fix by Heikki Linnakangas. Backpatch to all supported versions (9.4). Discussion: https://www.postgresql.org/message-id/20190731210630.nqhszuktygwftjty%40alap3.anarazel.de
Fix some incorrect parsing of time with time zone strings
commit : 1ba4d0fe463eaf16bc93024d0634cf224f07a0e8 author : Michael Paquier <firstname.lastname@example.org> date : Wed, 7 Aug 2019 18:17:46 +0900 committer: Michael Paquier <email@example.com> date : Wed, 7 Aug 2019 18:17:46 +0900
When parsing a timetz string with a dynamic timezone abbreviation or a timezone not specified, it was possible to generate incorrect timestamps based on a date which uses some non-initialized variables if the input string did not specify fully a date to parse. This is already checked when a full timezone spec is included in the input string, but the two other cases mentioned above missed the same checks. This gets fixed by generating an error as this input is invalid, or in short when a date is not fully specified. Valgrind was complaining about this problem. Bug: #15910 Author: Alexander Lakhin Discussion: https://firstname.lastname@example.org Backpatch-through: 9.4
Fix intarray's GiST opclasses to not fail for empty arrays with <@.
commit : 5b3e6c13f753cb10b476bf7755b5622aef2fbdce author : Tom Lane <email@example.com> date : Tue, 6 Aug 2019 18:04:51 -0400 committer: Tom Lane <firstname.lastname@example.org> date : Tue, 6 Aug 2019 18:04:51 -0400
contrib/intarray considers "arraycol <@ constant-array" to be indexable, but its GiST opclass code fails to reliably find index entries for empty array values (which of course should trivially match such queries). This is because the test condition to see whether we should descend through a non-leaf node is wrong. Unfortunately, empty array entries could be anywhere in the index, as these index opclasses are currently designed. So there's no way to fix this except by lobotomizing <@ indexscans to scan the whole index ... which is what this patch does. That's pretty unfortunate: the performance is now actually worse than a seqscan, in most cases. We'd be better off to remove <@ from the GiST opclasses entirely, and perhaps a future non-back-patchable patch will do so. In the meantime, applications whose performance is adversely impacted have a couple of options. They could switch to a GIN index, which doesn't have this bug, or they could replace "arraycol <@ constant-array" with "arraycol <@ constant-array AND arraycol && constant-array". That will provide about the same performance as before, and it will find all non-empty subsets of the given constant-array, which is all that could reliably be expected of the query before. While at it, add some more regression test cases to improve code coverage of contrib/intarray. In passing, adjust resize_intArrayType so that when it's returning an empty array, it uses construct_empty_array for that rather than cowboy hacking on the input array. While the hack produces an array that looks valid for most purposes, it isn't bitwise equal to empty arrays produced by other code paths, which could have subtle odd effects. I don't think this code path is performance-critical enough to justify such shortcuts. (Back-patch this part only as far as v11; before commit 01783ac36 we were not careful about this in other intarray code paths either.) Back-patch the <@ fixes to all supported versions, since this was broken from day one. Patch by me; thanks to Alexander Korotkov for review. Discussion: https://email@example.com