Fix thinko in construction of old_conpfeqop list.
commit : a6e7eb42d6112ba1c1a9b678a913a9de66a11ff9 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 : 63d1bc04d1fd0b99abba4b4d741494c68d86a68f 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 documentation for pgbench tpcb-like.
commit : 9dcf6d178a5119314b6bce604530072dc48022ce author : Thomas Munro <email@example.com> date : Sun, 14 Jul 2019 14:19:54 +1200 committer: Thomas Munro <firstname.lastname@example.org> 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
Fix variable initialization when using buffering build with GiST
commit : 6365f3ca24b821b1da21bf5b8f01fca73372de66 author : Michael Paquier <email@example.com> date : Wed, 10 Jul 2019 15:15:18 +0900 committer: Michael Paquier <firstname.lastname@example.org> 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://email@example.com Backpatch-through: 9.4
Don't remove surplus columns from GROUP BY for inheritance parents
commit : 388d05a5e1551e34e3908c2bfad21860adfcc5a7 author : David Rowley <firstname.lastname@example.org> date : Wed, 3 Jul 2019 23:46:26 +1200 committer: David Rowley <email@example.com> 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
Add support for Visual Studio 2019 in build scripts
commit : 78aaffd285c4a66452004f8f2c4ff2771cee4cb4 author : Michael Paquier <firstname.lastname@example.org> date : Wed, 3 Jul 2019 08:58:17 +0900 committer: Michael Paquier <email@example.com> 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
Fix tab completion of "SET variable TO|=" to not offer bogus completions.
commit : 47fe7a753db81370056d506703b58a38a9d591b0 author : Tom Lane <firstname.lastname@example.org> date : Tue, 2 Jul 2019 13:35:14 -0400 committer: Tom Lane <email@example.com> 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
Don't read fields of a misaligned ExpandedObjectHeader or AnyArrayType.
commit : 2938aa2a5b1cebb41f9e54c1ea289c286139c21e author : Noah Misch <firstname.lastname@example.org> date : Sun, 30 Jun 2019 17:34:17 -0700 committer: Noah Misch <email@example.com> 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/20190629210334.GA1244217@rfd.leadboat.com
Repair logic for reordering grouping sets optimization.
commit : 793eb94e31387738c72a8d7d702a6aecc9c5edee author : Andrew Gierth <firstname.lastname@example.org> date : Sun, 30 Jun 2019 23:49:29 +0100 committer: Andrew Gierth <email@example.com> 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
Fix misleading comment in nodeIndexonlyscan.c.
commit : 0908c5ecf0833b020b0d95183804ebc22bb6ea6c 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 : 30e1b395c9cfee997c9f44cfb27c3c6ec06b5a25 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 : 5329606693fcd132882c284abbb66bd296a24549 author : Michael Paquier <firstname.lastname@example.org> date : Wed, 26 Jun 2019 23:05:34 +0900 committer: Michael Paquier <email@example.com> 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://firstname.lastname@example.org Backpatch-through: 9.4
Don't unset MAKEFLAGS in non-GNU Makefile.
commit : 3a3b361ccbd8563f3b416e5ab5077b73dccd80e8 author : Thomas Munro <email@example.com> date : Tue, 25 Jun 2019 09:29:53 +1200 committer: Thomas Munro <firstname.lastname@example.org> 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
Further fix ALTER COLUMN TYPE's handling of indexes and index constraints.
commit : da1041fc3a2b65a6a36f1b8b91765a46e54e571e 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 : 9895e3a36a72beec296a319c0462a1aa691ead53 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
Consolidate methods for translating a Perl path to a Windows path.
commit : 186113b049c50a608b575e2597209e9eda99d83c author : Noah Misch <email@example.com> date : Fri, 21 Jun 2019 20:34:23 -0700 committer: Noah Misch <firstname.lastname@example.org> 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/20190610045838.GA238501@rfd.leadboat.com
Remove obsolete comments about sempahores from proc.c.
commit : fe755edc5c7613de062aeb111763ffa8e6b902c4 author : Thomas Munro <email@example.com> date : Fri, 21 Jun 2019 10:57:07 +1200 committer: Thomas Munro <firstname.lastname@example.org> 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
Avoid spurious deadlocks when upgrading a tuple lock
commit : 0ba35c7c9f8e16bdd33893d7236d4fb7fb633b0f author : Alvaro Herrera <email@example.com> date : Tue, 18 Jun 2019 18:23:16 -0400 committer: Alvaro Herrera <firstname.lastname@example.org> 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/B9C9D7CD-EB94-4635-91B6-E558ACEC0EC3@hintbits.com Discussion: https://email@example.com