doc: Fix typos
commit : b9a027c53a2a1efbe45413c83fc89412654a0d1c author : Peter Eisentraut <email@example.com> date : Wed, 25 Nov 2020 09:49:00 +0100 committer: Peter Eisentraut <firstname.lastname@example.org> date : Wed, 25 Nov 2020 09:49:00 +0100
Author: Justin Pryzby <email@example.com> Discussion: https://www.postgresql.org/message-id/20201121194105.GO24784@telsasoft.com
Properly check index mark/restore in ExecSupportsMarkRestore.
commit : 018e7d98dc157265efc4121e2b5971c0a2afcbe1 author : Andrew Gierth <firstname.lastname@example.org> date : Tue, 24 Nov 2020 20:58:32 +0000 committer: Andrew Gierth <email@example.com> date : Tue, 24 Nov 2020 20:58:32 +0000
Previously this code assumed that all IndexScan nodes supported mark/restore, which is not true since it depends on optional index AM support functions. This could lead to errors about missing support functions in rare edge cases of mergejoins with no sort keys, where an unordered non-btree index scan was placed on the inner path without a protecting Materialize node. (Normally, the fact that merge join requires ordered input would avoid this error.) Backpatch all the way since this bug is ancient. Per report from Eugen Konkov on irc. Discussion: https://firstname.lastname@example.org
Skip allocating hash table in EXPLAIN-only mode.
commit : 57b5d8484c8a0949c3fa8205a324ac7bf3a377fb author : Heikki Linnakangas <email@example.com> date : Fri, 20 Nov 2020 14:41:14 +0200 committer: Heikki Linnakangas <firstname.lastname@example.org> date : Fri, 20 Nov 2020 14:41:14 +0200
This is a backpatch of commit 2cccb627f1, backpatched due to popular demand. Backpatch to all supported versions. Author: Alexey Bashtanov Discussion: https://www.postgresql.org/message-id/36823f65-050d-ae24-aa4d-a37726998240%40imap.cc
On macOS, use -isysroot in link steps as well as compile steps.
commit : d01e37845c2262a0b51a59c77ff8ad7b855824f8 author : Tom Lane <email@example.com> date : Fri, 20 Nov 2020 00:58:26 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Fri, 20 Nov 2020 00:58:26 -0500
We previously put the -isysroot switch only into CPPFLAGS, theorizing that it was only needed to find the right copies of include files. However, it seems that we also need to use it while linking programs, to find the right stub ".tbd" files for libraries. We got away without that up to now, but apparently that was mostly luck. It may also be that failures are only observed when the Xcode version is noticeably out of sync with the host macOS version; the case that's prompting action right now is that builds fail when using latest Xcode (12.2) on macOS Catalina, even though it's fine on Big Sur. Hence, add -isysroot to LDFLAGS as well. (It seems that the more common practice is to put it in CFLAGS, whence it'd be included at both compile and link steps. However, we can't mess with CFLAGS in the platform template file without confusing configure's logic for choosing default CFLAGS.) Back-patch of 49407dc32 into all supported branches. Report and patch by James Hilliard (some cosmetic mods by me) Discussion: https://email@example.com
Adjust DSM and DSA slot usage constants (back-patch).
commit : 0455f78ddbb09b6ad3bb6b582b75fd3975a24541 author : Thomas Munro <firstname.lastname@example.org> date : Fri, 20 Nov 2020 10:44:09 +1300 committer: Thomas Munro <email@example.com> date : Fri, 20 Nov 2020 10:44:09 +1300
1. Previously, a DSA area would create up to four segments at each size before doubling the size. After this commit, it will create only two at each size, so it ramps up faster and therefore needs fewer slots. 2. Previously, the total limit on DSM slots allowed for 2 per connection. Switch to 5 per connection. This back-patches commit d061ea21 from release 13 into 10-12 based on a field complaint. Discussion: https://postgr.es/m/CAO03teA%2BjE1qt5iWDWzHqaufqBsF6EoOgZphnazps_tr_jDPZA%40mail.gmail.com Discussion: https://postgr.es/m/CA%2BhUKGL6H2BpGbiF7Lj6QiTjTGyTLW_vLR%3DSn2tEBeTcYXiMKw%40mail.gmail.com
Further fixes for CREATE TABLE LIKE: cope with self-referential FKs.
commit : c690ebbefa3394b67ceb1ba913590d873ad40355 author : Tom Lane <firstname.lastname@example.org> date : Thu, 19 Nov 2020 15:03:17 -0500 committer: Tom Lane <email@example.com> date : Thu, 19 Nov 2020 15:03:17 -0500
Commit 502898192 was too careless about the order of execution of the additional ALTER TABLE operations generated by expandTableLikeClause. It just stuck them all at the end, which seems okay for most purposes. But it falls down in the case where LIKE is importing a primary key or unique index and the outer CREATE TABLE includes a FOREIGN KEY constraint that needs to depend on that index. Weird as that is, it used to work, so we ought to keep it working. To fix, make parse_utilcmd.c insert LIKE clauses between index-creation and FK-creation commands in the transformed list of commands, and change utility.c so that the commands generated by expandTableLikeClause are executed immediately not at the end. One could imagine scenarios where this wouldn't work either; but currently expandTableLikeClause only makes column default expressions, CHECK constraints, and indexes, and this ordering seems fine for those. Per bug #16730 from Sofoklis Papasofokli. Like the previous patch, back-patch to all supported branches. Discussion: https://firstname.lastname@example.org
Don't Insert() a VFD entry until it's fully built.
commit : 6b8235d035650d732b11c4e38f07c722496db0b9 author : Tom Lane <email@example.com> date : Mon, 16 Nov 2020 20:32:35 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Mon, 16 Nov 2020 20:32:35 -0500
Otherwise, if FDDEBUG is enabled, the debugging output fails because it tries to read the fileName, which isn't set up yet (and should in fact always be NULL). AFAICT, this has been wrong since Berkeley. Before 96bf88d52, it would accidentally fail to crash on platforms where snprintf() is forgiving about being passed a NULL pointer for %s; but the file name intended to be included in the debug output wouldn't ever have shown up. Report and fix by Greg Nancarrow. Although this is only visibly broken in custom-made builds, it still seems worth back-patching to all supported branches, as the FDDEBUG code is pretty useless as it stands. Discussion: https://postgr.es/m/CAJcOf-cUDgm9qYtC_B6XrC6MktMPNRby2p61EtSGZKnfotMArw@mail.gmail.com
Do not return NULL for error cases in satisfies_hash_partition().
commit : 84e31622882358f61e9d3c16c5b4f3187f504a68 author : Tom Lane <email@example.com> date : Mon, 16 Nov 2020 16:39:59 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Mon, 16 Nov 2020 16:39:59 -0500
Since this function is used as a CHECK constraint condition, returning NULL is tantamount to returning TRUE, which would have the effect of letting in a row that doesn't satisfy the hash condition. Admittedly, the cases for which this is done should be unreachable in practice, but that doesn't make it any less a bad idea. It also seems like a dartboard was used to decide which error cases should throw errors as opposed to returning NULL. For the checks for NULL input values, I just switched it to returning false. There's some argument that an error would be better; but the case really should be can't-happen in a generated hash constraint, so it's likely not worth more code for. For the parent-relation-open-failure case, it seems like we might as well let relation_open throw an error, instead of having an impossible-to-diagnose constraint failure. Back-patch to v11 where this code came in. Discussion: https://email@example.com
Use "true" not "TRUE" in one ICU function call.
commit : 89aa30a179686d86aeccddf715f039d1a15d2b30 author : Tom Lane <firstname.lastname@example.org> date : Mon, 16 Nov 2020 15:16:39 -0500 committer: Tom Lane <email@example.com> date : Mon, 16 Nov 2020 15:16:39 -0500
This was evidently missed in commit 6337865f3, which generally did s/TRUE/true/ everywhere. It escaped notice up to now because ICU versions before ICU 68 provided definitions of "TRUE" and "FALSE" regardless. With ICU 68, it fails to compile. Per report from Condor. Back-patch to v11 where 6337865f3 came in. (I've not tested v10, where this call originated, but I imagine it's fine since we defined TRUE in c.h back then.) Discussion: https://firstname.lastname@example.org
doc: update bgwriter description
commit : bea246117b402e59340c9efa0bdbdbe7c1ea8554 author : Bruce Momjian <email@example.com> date : Mon, 16 Nov 2020 13:13:43 -0500 committer: Bruce Momjian <firstname.lastname@example.org> date : Mon, 16 Nov 2020 13:13:43 -0500
This clarifies exactly what the bgwriter does, which should help with tuning. Reported-by: Chris Wilson Discussion: https://email@example.com Backpatch-through: 9.5
doc: clarify how to find pg_type_d.h in the install tree
commit : 524712ceae3b443e19b54ad877d26558af7ee3d0 author : Bruce Momjian <firstname.lastname@example.org> date : Mon, 16 Nov 2020 12:36:16 -0500 committer: Bruce Momjian <email@example.com> date : Mon, 16 Nov 2020 12:36:16 -0500
Followup to patch 152ed04799. Reported-by: Alvaro Herrera Discussion: https://postgr.es/m/20201112202900.GA28098@alvherre.pgsql Backpatch-through: 9.5
doc: adjust expression index analyze working some more
commit : 9425c90cc3e16c2779e3e413030b53206e625508 author : Bruce Momjian <firstname.lastname@example.org> date : Mon, 16 Nov 2020 11:14:54 -0500 committer: Bruce Momjian <email@example.com> date : Mon, 16 Nov 2020 11:14:54 -0500
This applies the fix bcbd771332 to skipped branches. Reported-by: Erik Rijkers Discussion: https://firstname.lastname@example.org Backpatch-through: 9.5-11
doc: improve wording of the need for analyze of exp. indexes
commit : 2c2ab4b9cb311a314e795653bd500f10c3955566 author : Bruce Momjian <email@example.com> date : Mon, 16 Nov 2020 10:26:16 -0500 committer: Bruce Momjian <firstname.lastname@example.org> date : Mon, 16 Nov 2020 10:26:16 -0500
This is a followup commit on 3370207986. Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20201112211143.GL30691@telsasoft.com Backpatch-through: 9.5
Fix fuzzy thinking about amcanmulticol versus amcaninclude.
commit : 9cebe49524af365d48f9e63048c79f537d6b135c author : Tom Lane <email@example.com> date : Sun, 15 Nov 2020 16:10:48 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Sun, 15 Nov 2020 16:10:48 -0500
These flags should be independent: in particular an index AM should be able to say that it supports include columns without necessarily supporting multiple key columns. The included-columns patch got this wrong, possibly aided by the fact that it didn't bother to update the documentation. While here, clarify some text about amcanreturn, which was a little vague about what should happen when amcanreturn reports that only some of the index columns are returnable. Noted while reviewing the SP-GiST included-columns patch, which quite incorrectly (and unsafely) changed SP-GiST to claim amcanmulticol = true as a workaround for this bug. Backpatch to v11 where included columns were introduced.
Doc: improve partitioning discussion in ddl.sgml.
commit : a87d7801c24ffb3593841838ba0e3d4883d34853 author : Tom Lane <email@example.com> date : Sat, 14 Nov 2020 13:09:53 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Sat, 14 Nov 2020 13:09:53 -0500
This started with the intent to explain that range upper bounds are exclusive, which previously you could only find out by reading the CREATE TABLE man page. But I soon found that section 5.11 really could stand a fair amount of editorial attention. It's apparently been revised several times without much concern for overall flow, nor careful copy-editing. Back-patch to v11, which is as far as the patch goes easily. Per gripe from Edson Richter. Thanks to David Johnston for review. Discussion: https://postgr.es/m/DM6PR13MB3988736CF8F5DC5720440231CFE60@DM6PR13MB3988.namprd13.prod.outlook.com
doc: clarify where to find pg_type_d.h (PG 11+) and pg_type.h
commit : e60f4a3fc045790d91b4aacab31b37489b697f0a author : Bruce Momjian <email@example.com> date : Thu, 12 Nov 2020 15:13:01 -0500 committer: Bruce Momjian <firstname.lastname@example.org> date : Thu, 12 Nov 2020 15:13:01 -0500
These files are in compiled directories and install directories. Reported-by: email@example.com Discussion: https://firstname.lastname@example.org Backpatch-through: 9.5
docs: mention that expression indexes need analyze
commit : b740b4a86784f40a4a473dc754525919e6abbc22 author : Bruce Momjian <email@example.com> date : Thu, 12 Nov 2020 15:00:44 -0500 committer: Bruce Momjian <firstname.lastname@example.org> date : Thu, 12 Nov 2020 15:00:44 -0500
Expression indexes can't benefit from pre-computed statistics on columns. Reported-by: Nikolay Samokhvalov Discussion: https://postgr.es/m/CANNMO++5rw9RDA=p40iMVbMNPaW6O=S0AFzTU=KpYHRpCd1voA@mail.gmail.com Author: Nikolay Samokhvalov, modified Backpatch-through: 9.5
doc: wire protocol data type for history file content is bytea
commit : b5b7072a6725a2564c43b88feb5c7bb38862d4e8 author : Bruce Momjian <email@example.com> date : Thu, 12 Nov 2020 14:33:28 -0500 committer: Bruce Momjian <firstname.lastname@example.org> date : Thu, 12 Nov 2020 14:33:28 -0500
Document that though the history file content is marked as bytea, it is the same a text, and neither is btyea-escaped or encoding converted. Reported-by: Brar Piening Discussion: https://email@example.com Backpatch-through: 13 - 9.5 (not master)
pg_trgm: fix crash in 2-item picksplit
commit : 7e3dc147d0a8364fb39f3229031cd6bf44180307 author : Andrew Gierth <firstname.lastname@example.org> date : Thu, 12 Nov 2020 14:34:37 +0000 committer: Andrew Gierth <email@example.com> date : Thu, 12 Nov 2020 14:34:37 +0000
Whether from size overflow in gistSplit or from secondary splits, picksplit is (rarely) called with exactly two items to split. Formerly, due to special-case handling of the last item, this would lead to access to an uninitialized cache entry; prior to PG 13 this might have been harmless or at worst led to an incorrect union datum, but in 13 onwards it can cause a backend crash from using an uninitialized pointer. Repair by removing the special case, which was deemed not to have been appropriate anyway. Backpatch all the way, because this bug has existed since pg_trgm was added. Per report on IRC from user "ftzdomino". Analysis and testing by me, patch from Alexander Korotkov. Discussion: https://firstname.lastname@example.org
Remove duplicate code in brin_memtuple_initialize
commit : c4424d33cca9719ae925d0cc018acf32182a6d95 author : Tomas Vondra <email@example.com> date : Wed, 11 Nov 2020 18:37:36 +0100 committer: Tomas Vondra <firstname.lastname@example.org> date : Wed, 11 Nov 2020 18:37:36 +0100
Commit 8bf74967dab moved some of the code from brin_new_memtuple to brin_memtuple_initialize, but this resulted in some of the code being duplicate. Fix by removing the duplicate lines and backpatch to 10. Author: Tomas Vondra Backpatch-through: 10 Discussion: https://postgr.es/m/5eb50c97-9a8e-b691-8c40-1b2a55611c4c%40enterprisedb.com
Fix and simplify some usages of TimestampDifference().
commit : 3a89ea0eb64a1b50b27de1965fdb2173a04d5e11 author : Tom Lane <email@example.com> date : Tue, 10 Nov 2020 22:51:19 -0500 committer: Tom Lane <firstname.lastname@example.org> date : Tue, 10 Nov 2020 22:51:19 -0500
Introduce TimestampDifferenceMilliseconds() to simplify callers that would rather have the difference in milliseconds, instead of the select()-oriented seconds-and-microseconds format. This gets rid of at least one integer division per call, and it eliminates some apparently-easy-to-mess-up arithmetic. Two of these call sites were in fact wrong: * pg_prewarm's autoprewarm_main() forgot to multiply the seconds by 1000, thus ending up with a delay 1000X shorter than intended. That doesn't quite make it a busy-wait, but close. * postgres_fdw's pgfdw_get_cleanup_result() thought it needed to compute microseconds not milliseconds, thus ending up with a delay 1000X longer than intended. Somebody along the way had noticed this problem but misdiagnosed the cause, and imposed an ad-hoc 60-second limit rather than fixing the units. This was relatively harmless in context, because we don't care that much about exactly how long this delay is; still, it's wrong. There are a few more callers of TimestampDifference() that don't have a direct need for seconds-and-microseconds, but can't use TimestampDifferenceMilliseconds() either because they do need microsecond precision or because they might possibly deal with intervals long enough to overflow 32-bit milliseconds. It might be worth inventing another API to improve that, but that seems outside the scope of this patch; so those callers are untouched here. Given the fact that we are fixing some bugs, and the likelihood that future patches might want to back-patch code that uses this new API, back-patch to all supported branches. Alexey Kondratov and Tom Lane Discussion: https://email@example.com
doc: fix spelling "connction" to "connection"
commit : 9fed2b5b2eddba03bda7d62376186b141630ce38 author : Bruce Momjian <firstname.lastname@example.org> date : Tue, 10 Nov 2020 19:18:35 -0500 committer: Bruce Momjian <email@example.com> date : Tue, 10 Nov 2020 19:18:35 -0500
Was wrong in commit 1a9388bd0f. Reported-by: Tom Lane, Justin Pryzby Discussion: https://postgr.es/m/20201102063333.GE22691@telsasoft.com Backpatch-through: 9.5
Work around cross-version-upgrade issues created by commit 9e38c2bb5.
commit : d3d4f7233a3e16dcbaa95f62e7559d147790b574 author : Tom Lane <firstname.lastname@example.org> date : Tue, 10 Nov 2020 18:32:36 -0500 committer: Tom Lane <email@example.com> date : Tue, 10 Nov 2020 18:32:36 -0500
Summarily changing the STYPE of regression-test aggregates that depend on array_append or array_cat is an issue for the buildfarm's cross-version-upgrade tests, because those aggregates (as defined in the back branches) now won't load into HEAD. Although this seems like only a minimal risk for genuine user-defined aggregates, we need to do something for the buildfarm. Hence, adjust the aggregate definitions, in both HEAD and the back branches. Discussion: https://firstname.lastname@example.org Discussion: https://postgr.es/m/E1kaQ2c-0005lx-Eg@gemulon.postgresql.org