Skip to main content

Browse the archive

https://github.com/postgres/postgres
14 July 2024, 23:53:18 UTC
sort by:
Revision Author Date Message Commit Date
17822c0 Tom Lane 23 September 2019, 20:24:42 UTC Stamp 12rc1. 23 September 2019, 20:24:42 UTC
53c89ae Tom Lane 23 September 2019, 17:04:52 UTC Doc: more contributor name cleanup. Further adjust Japanese names, per advice from Etsuro Fujita. Discussion: https://postgr.es/m/CAPmGK15XT8eCwn1j3tB3CnOn2q6ksHNKwKjDrEcca5ZEfG0tng@mail.gmail.com 23 September 2019, 17:04:52 UTC
216bcf5 Tom Lane 23 September 2019, 16:37:04 UTC Doc: clarify handling of duplicate elements in array containment tests. The array <@ and @> operators do not worry about duplicates: if every member of array X matches some element of array Y, then X is contained in Y, even if several members of X get matched to the same Y member. This was not explicitly stated in the docs though, so improve matters. Discussion: https://postgr.es/m/156614120484.1310.310161642239149585@wrigleys.postgresql.org 23 September 2019, 16:37:04 UTC
a25fb9c Tom Lane 23 September 2019, 14:40:42 UTC Doc: proofreading for v12 release notes. Mostly markup improvements, with a couple of grammar fixes. Liudmila Mantrova Discussion: https://postgr.es/m/CAEkD-mDxVV1Hrxzo3-hPaS5b1s-+Gin+9Cbu2eMBqRovRVjC0w@mail.gmail.com 23 September 2019, 14:40:42 UTC
ac8fb2c Tom Lane 23 September 2019, 14:32:02 UTC Doc: clean up some issues with spellings of contributor names. In the v12 contributors list, remove a couple of duplicates that had crept in due to variant spellings of a person's name. Try to standardize Japanese names as given-name-first. Alexander Lakhin Discussion: https://postgr.es/m/a8263c91-6a21-61d4-3156-34bf2fe54e15@gmail.com 23 September 2019, 14:32:02 UTC
8cdd1c4 Peter Eisentraut 23 September 2019, 13:30:41 UTC Translation updates Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 8a42b829ebeb8b22db0e3258ec02137f8840b960 23 September 2019, 13:30:41 UTC
516a4c1 Peter Eisentraut 23 September 2019, 11:37:33 UTC Message style fixes 23 September 2019, 11:37:33 UTC
84eb871 Peter Eisentraut 23 September 2019, 07:04:20 UTC NLS: Fix backend gettext triggers The backend also needs to pull in translations from the frontend pg_log_*() functions, since some files in src/common/ use those. 23 September 2019, 07:05:50 UTC
860216e Tom Lane 22 September 2019, 21:46:00 UTC Fix failure to zero-pad the result of bitshiftright(). If the bitstring length is not a multiple of 8, we'd shift the rightmost bits into the pad space, which must be zeroes --- bit_cmp, for one, depends on that. This'd lead to the result failing to compare equal to what it should compare equal to, as reported in bug #16013 from Daryl Waycott. This is, if memory serves, not the first such bug in the bitstring functions. In hopes of making it the last one, do a bit more work than minimally necessary to fix the bug: * Add assertion checks to bit_out() and varbit_out() to complain if they are given incorrectly-padded input. This will improve the odds that manual testing of any new patch finds problems. * Encapsulate the padding-related logic in macros to make it easier to use. Also, remove unnecessary padding logic from bit_or() and bitxor(). Somebody had already noted that we need not re-pad the result of bit_and() since the inputs are required to be the same length, but failed to extrapolate that to the other two. Also, move a comment block that once was near the head of varbit.c (but people kept putting other stuff in front of it), to put it in the header block. Note for the release notes: if anyone has inconsistent data as a result of saving the output of bitshiftright() in a table, it's possible to fix it with something like UPDATE mytab SET bitcol = ~(~bitcol) WHERE bitcol != ~(~bitcol); This has been broken since day one, so back-patch to all supported branches. Discussion: https://postgr.es/m/16013-c2765b6996aacae9@postgresql.org 22 September 2019, 21:46:00 UTC
3088138 Tom Lane 22 September 2019, 18:21:07 UTC Fix typo in tts_virtual_copyslot. The code used the destination slot's natts where it intended to use the source slot's natts. Adding an Assert shows that there is no case in "make check-world" where these counts are different, so maybe this is a harmless bug, but it's still a bug. Takayuki Tsunakawa Discussion: https://postgr.es/m/0A3221C70F24FB45833433255569204D1FD34C0E@G01JPEXMBYT05 22 September 2019, 18:21:07 UTC
ee98ade Peter Eisentraut 21 September 2019, 21:22:15 UTC Remove removed file from nls.mk part of revert "Add DECLARE STATEMENT support to ECPG." 21 September 2019, 21:22:15 UTC
87b6016 Peter Eisentraut 21 September 2019, 20:51:54 UTC Update list of acknowledgments in release notes current through 25f9368304e41c8837f59e94b161f07ac4c7d622 21 September 2019, 20:57:23 UTC
d9110d7 Tom Lane 21 September 2019, 20:56:30 UTC Straighten out leakproofness markings on text comparison functions. Since we introduced the idea of leakproof functions, texteq and textne were marked leakproof but their sibling text comparison functions were not. This inconsistency seemed justified because texteq/textne just relied on memcmp() and so could easily be seen to be leakproof, while the other comparison functions are far more complex and indeed can throw input-dependent errors. However, that argument crashed and burned with the addition of nondeterministic collations, because now texteq/textne may invoke the exact same varstr_cmp() infrastructure as the rest. It makes no sense whatever to give them different leakproofness markings. After a certain amount of angst we've concluded that it's all right to consider varstr_cmp() to be leakproof, mostly because the other choice would be disastrous for performance of many queries where leakproofness matters. The input-dependent errors should only be reachable for corrupt input data, or so we hope anyway; certainly, if they are reachable in practice, we've got problems with requirements as basic as maintaining a btree index on a text column. Hence, run around to all the SQL functions that derive from varstr_cmp() and mark them leakproof. This should result in a useful gain in flexibility/performance for queries in which non-leakproofness degrades the efficiency of the query plan. Back-patch to v12 where nondeterministic collations were added. While this isn't an essential bug fix given the determination that varstr_cmp() is leakproof, we might as well apply it now that we've been forced into a post-beta4 catversion bump. Discussion: https://postgr.es/m/31481.1568303470@sss.pgh.pa.us 21 September 2019, 20:56:30 UTC
d3c61e8 Tom Lane 21 September 2019, 20:29:17 UTC Fix up handling of nondeterministic collations with pattern_ops opclasses. text_pattern_ops and its siblings can't be used with nondeterministic collations, because they use the text_eq operator which will not behave as bitwise equality if applied with a nondeterministic collation. The initial implementation of that restriction was to insert a run-time test in the related comparison functions, but that is inefficient, may throw misleading errors, and will throw errors in some cases that would work. It seems sufficient to just prevent the combination during CREATE INDEX, so do that instead. Lacking any better way to identify the opclasses involved, we need to hard-wire tests for them, which requires hand-assigned values for their OIDs, which forces a catversion bump because they previously had OIDs that would be assigned automatically. That's slightly annoying in the v12 branch, but fortunately we're not at rc1 yet, so just do it. Back-patch to v12 where nondeterministic collations were added. In passing, run make reformat-dat-files, which found some unrelated whitespace issues (slightly different ones in HEAD and v12). Peter Eisentraut, with small corrections by me Discussion: https://postgr.es/m/22566.1568675619@sss.pgh.pa.us 21 September 2019, 20:29:17 UTC
25f9368 Tom Lane 21 September 2019, 19:23:53 UTC Doc: updates for v12 release notes. Remove mention of ECPG's DECLARE STATEMENT, since that was reverted yesterday. Rewrite some other entries per suggestions from Peter Eisentraut. Make a couple of desultory wording and markup adjustments. Discussion: https://postgr.es/m/d4dff575-90ab-9c8c-cc6f-8c657e2de665@2ndquadrant.com 21 September 2019, 19:23:53 UTC
2966e30 Tom Lane 20 September 2019, 23:53:33 UTC Update time zone data files to tzdata release 2019c. DST law changes in Fiji and Norfolk Island. Historical corrections for Alberta, Austria, Belgium, British Columbia, Cambodia, Hong Kong, Indiana (Perry County), Kaliningrad, Kentucky, Michigan, Norfolk Island, South Korea, and Turkey. 20 September 2019, 23:53:52 UTC
5f3bec0 Tom Lane 20 September 2019, 18:22:58 UTC Fix some minor spec-compliance issues in jsonpath lexer. Although the SQL/JSON tech report makes reference to ECMAScript which allows both single- and double-quoted strings, all the rest of the report speaks only of double-quoted string literals in jsonpaths. That's more compatible with JSON itself; moreover single-quoted strings are hard to use inside a jsonpath that is itself a single-quoted SQL literal. So guess that the intent is to allow only double-quoted literals, and remove lexer support for single-quoted literals. It'll be less painful to add this again later if we're wrong, than to remove a shipped feature. Also, adjust the lexer so that unrecognized backslash sequences are treated as just meaning the escaped character, not as errors. This change has much better support in the standards, as JSON, JavaScript and ECMAScript all make it plain that that's what's supposed to happen. Back-patch to v12. Discussion: https://postgr.es/m/CAPpHfdvDci4iqNF9fhRkTqhe-5_8HmzeLt56drH%2B_Rv2rNRqfg@mail.gmail.com 20 September 2019, 18:22:58 UTC
08e04a5 Tom Lane 20 September 2019, 16:47:21 UTC Revert "Add DECLARE STATEMENT support to ECPG." This reverts commit bd7c95f0c1a38becffceb3ea7234d57167f6d4bf, along with assorted follow-on fixes. There are some questions about the definition and implementation of that statement, and we don't have time to resolve them before v13 release. Rather than ship the feature and then have backwards-compatibility concerns constraining any redesign, let's remove it for now and try again later. Discussion: https://postgr.es/m/TY2PR01MB2443EC8286995378AEB7D9F8F5B10@TY2PR01MB2443.jpnprd01.prod.outlook.com 20 September 2019, 16:47:38 UTC
c3c131e Alvaro Herrera 20 September 2019, 15:53:58 UTC Fix progress report of REINDEX INDEX I (Álvaro) broke that in commit 6212276e4343 -- forgot to set the necessary flag. Repair. Author: Amit Langote Discussion: https://postgr.es/m/CA+HiwqEaM2tV5awKhP1vSbgjQe_uXVU15Oi4sTgwgempwMiT8g@mail.gmail.com 20 September 2019, 15:55:35 UTC
d75386a Alexander Korotkov 20 September 2019, 12:31:12 UTC Provide stable test for NULL-values in KNN SP-GiST f5f084fc3e has removed test because of its instability. This commit provides alternative test with determined ordering using extra ORDER BY expression. Backpatch-through: 12 20 September 2019, 12:35:32 UTC
09f8106 Amit Kapila 20 September 2019, 02:08:06 UTC Fix typo in commit 82fa3ff8672. Reported-By: Kuntal Ghosh (off-list) Backpatch-through: 9.4, like 82fa3ff8672 20 September 2019, 02:16:39 UTC
340536d Alexander Korotkov 19 September 2019, 22:46:49 UTC Remove unstable KNN SP-GiST test 6cae9d2c10 introduced test for NULL values in KNN SP-GiST. This test relies on undetermined ordering showing different results on various platforms. This commit removes that test. Will be replaced with better test later. Discussion: https://postgr.es/m/6d51305e1159241cabee132f7efc7eff%40xs4all.nl Backpatch-through: 12 19 September 2019, 22:51:23 UTC
8c58e48 Alexander Korotkov 19 September 2019, 22:10:56 UTC Fix freeing old values in index_store_float8_orderby_distances() 6cae9d2c10 has added an error in freeing old values in index_store_float8_orderby_distances() function. It looks for old value in scan->xs_orderbynulls[i] after setting a new value there. This commit fixes that. Also it removes short-circuit in handling distances == NULL situation. Now distances == NULL will be treated the same way as array with all null distances. That is, previous values will be freed if any. Reported-by: Tom Lane, Nikita Glukhov Discussion: https://postgr.es/m/CAPpHfdu2wcoAVAm3Ek66rP%3Duo_C-D84%2B%2Buf1VEcbyi_caBXWCA%40mail.gmail.com Discussion: https://postgr.es/m/426580d3-a668-b9d1-7b8e-f74d1a6524e0%40postgrespro.ru Backpatch-through: 12 19 September 2019, 22:20:07 UTC
31cbd76 Alexander Korotkov 19 September 2019, 18:30:19 UTC Improve handling of NULLs in KNN-GiST and KNN-SP-GiST This commit improves subject in two ways: * It removes ugliness of 02f90879e7, which stores distance values and null flags in two separate arrays after GISTSearchItem struct. Instead we pack both distance value and null flag in IndexOrderByDistance struct. Alignment overhead should be negligible, because we typically deal with at most few "col op const" expressions in ORDER BY clause. * It fixes handling of "col op NULL" expression in KNN-SP-GiST. Now, these expression are not passed to support functions, which can't deal with them. Instead, NULL result is implicitly assumed. It future we may decide to teach support functions to deal with NULL arguments, but current solution is bugfix suitable for backpatch. Reported-by: Nikita Glukhov Discussion: https://postgr.es/m/826f57ee-afc7-8977-c44c-6111d18b02ec%40postgrespro.ru Author: Nikita Glukhov Reviewed-by: Alexander Korotkov Backpatch-through: 9.4 19 September 2019, 18:49:07 UTC
b9cf94c Tom Lane 19 September 2019, 15:22:21 UTC Doc: improve documentation around jsonpath regular expressions. Provide some documentation about the differences between XQuery regular expressions and those supported by Spencer's regex engine. Since SQL now exposes XQuery regexps with the LIKE_REGEX operator, I made this a standalone section designed to help somebody who has to translate a LIKE_REGEX query to Postgres. (Eventually we might extend Spencer's engine to allow precise implementation of XQuery, but not today.) Reference that in the jsonpath docs, provide definitions of the XQuery flag letters, and add a description of the JavaScript-inspired string literal syntax used within jsonpath. Also point out explicitly that backslashes used within like_regex patterns will need to be doubled. This also syncs the docs with the decision implemented in commit d5b90cd64 to desupport XQuery's 'x' flag for now. Jonathan Katz and Tom Lane Discussion: https://postgr.es/m/CAPpHfdvDci4iqNF9fhRkTqhe-5_8HmzeLt56drH%2B_Rv2rNRqfg@mail.gmail.com 19 September 2019, 15:22:21 UTC
596cf9e Peter Eisentraut 19 September 2019, 13:03:23 UTC GSSAPI error message improvements Make the error messages around GSSAPI encryption a bit clearer. Tweak some messages to avoid plural problems. Also make a code change for clarity. Using "conf" for "confidential" is quite confusing. Using "conf_state" is perhaps not much better but that's what the GSSAPI documentation uses, so there is at least some hope of understanding it. 19 September 2019, 13:09:38 UTC
9c4f200 Peter Eisentraut 19 September 2019, 09:46:40 UTC doc: Improve a release notes item 19 September 2019, 09:46:40 UTC
a4188a6 Amit Kapila 19 September 2019, 09:10:09 UTC Fix typo in commit 578b229718. Reported-by: Filip Rembiałkowski Author: Filip Rembiałkowski Backpatch-through: 12, where it was introduced Discussion: https://postgr.es/m/CAP_rwwmSNy1=_82rwGe3-X4PjWqPSFXtzNf43DCtGzD7SazdXA@mail.gmail.com 19 September 2019, 09:21:56 UTC
1aaa3ee Peter Eisentraut 19 September 2019, 07:58:43 UTC doc: Some release notes tweaking Improve the LDAP DNS SRV item. 19 September 2019, 07:58:43 UTC
fbd1cb2 Peter Eisentraut 19 September 2019, 07:02:41 UTC Revert change of ecpglib major version The major version of ecpglib was changed in bd7c95f0c1a38becffceb3ea7234d57167f6d4bf, apparently without justification. Revert this, since nothing has changed in this library except some added functions. Discussion: https://www.postgresql.org/message-id/flat/48ee4c56-e1df-b39d-2cad-c7d80b120eb5%402ndquadrant.com 19 September 2019, 07:02:41 UTC
ae2d826 Michael Paquier 19 September 2019, 04:19:00 UTC Doc: Fix incorrect mention to connection_object in CONNECT command of ECPG This fixes an inconsistency with this parameter name not listed in the command synopsis, and connection_name is the parameter name more commonly used in the docs for ECPG commands. Reported-by: Yusuke Egashita Discussion: https://postgr.es/m/156870956796.1259.11456186889345212399@wrigleys.postgresql.org Backpatch-through: 9.4 19 September 2019, 04:19:00 UTC
62ed5e7 Amit Kapila 19 September 2019, 02:32:12 UTC Doc: document autovacuum interruption. It's important users be able to know (without looking at the source code) that running DDL or DDL-like commands can interrupt autovacuum which can lead to a lot of dead tuples and hence slower database operations. Reported-by: James Coleman Author: James Coleman Reviewed-by: Amit Kapila Backpatch-through: 9.4 Discussion: https://postgr.es/m/CAAaqYe-XYyNwML1=f=gnd0qWg46PnvD=BDrCZ5-L94B887XVxQ@mail.gmail.com 19 September 2019, 03:28:11 UTC
cb23c63 Alvaro Herrera 18 September 2019, 14:24:12 UTC pg_upgrade/test.sh: Quote sed(1) argument Lack of quotes results in failure to run the test under older Solaris. Author: Marina Polyakova, Victor Wagner Discussion: https://postgr.es/m/feba89f89e8925b3535cb7d72b9e05e1@postgrespro.ru 18 September 2019, 14:26:46 UTC
68c3c49 Etsuro Fujita 18 September 2019, 09:50:01 UTC Doc: Update FDW documentation about direct foreign table modification. 1. Commit 7086be6e3 should have documented the limitation that the direct modification is disabled when WCO constraints are present, but didn't, which is definitely my fault. Update the documentation (Postgres 9.6 onwards). 2. Commit fc22b6623 should have documented the limitation that the direct modification is disabled when generated columns are defined, but didn't. Update the documentation (Postgres 12 onwards). Author: Etsuro Fujita Discussion: https://postgr.es/m/CAPmGK14AYCPunLb6TRz1CQsW5Le01Z2ox8LSOKH0P-cOVDcQRA%40mail.gmail.com 18 September 2019, 09:50:01 UTC
1488814 Tom Lane 17 September 2019, 19:39:51 UTC Fix bogus handling of XQuery regex option flags. The SQL spec defers to XQuery to define what the option flags are for LIKE_REGEX patterns. XQuery says that: * 's' allows the dot character to match newlines, which by default it will not; * 'm' allows ^ and $ to match at newlines, not only at the start/end of the whole string. Thus, these are *not* inverses as they are for the similarly-named POSIX options, and neither one corresponds to the POSIX 'n' option. Fortunately, Spencer's library does expose these two behaviors as separately twiddlable flags, so we just have to fix the mapping from JSP flag bits to REG flag bits. I also chose to rename the symbol for 's' to DOTALL, to make it clearer that it's not the inverse of MLINE. Also, XQuery says that if the 'q' flag "is used together with the m, s, or x flag, that flag has no effect". I read this as saying that 'q' overrides the other flags; whoever wrote our code seems to have read it backwards. Lastly, while XQuery's 'x' flag is related to what Spencer's code does for REG_EXPANDED, it's not the same or a subset. It seems best to treat XQuery's 'x' as unimplemented for now. Maybe later we can expand our regex code to offer 'x'-style parsing as a separate option. While at it, refactor the jsonpath code so that (a) there's only one copy of the flag transformation logic not two, and (b) the processing of flags is independent of the order in which the flags are written. We need some documentation updates to go with this, but I'll tackle that separately. Back-patch to v12 where this code originated. Discussion: https://postgr.es/m/CAPpHfdvDci4iqNF9fhRkTqhe-5_8HmzeLt56drH%2B_Rv2rNRqfg@mail.gmail.com Reference: https://www.w3.org/TR/2017/REC-xpath-functions-31-20170321/#flags 17 September 2019, 19:39:51 UTC
27bc879 Tom Lane 15 September 2019, 15:51:57 UTC Fix bogus sizeof calculations. Noted by Coverity. Typo in 27cc7cd2b, so back-patch to v12 as that was. 15 September 2019, 15:51:57 UTC
5576cbc Dean Rasheed 15 September 2019, 12:16:59 UTC Fix intermittent self-test failures caused by the stats_ext test. Commit d7f8d26d9 added new tests to the stats_ext regression test that included creating a view in the public schema, without realising that the stats_ext test runs in the same parallel group as the rules test, which makes doing that unsafe. This led to intermittent failures of the rules test on the buildfarm, although I wasn't able to reproduce that locally. Fix by creating the view in a different schema. Tomas Vondra and Dean Rasheed, report and diagnosis by Thomas Munro. Discussion: https://postgr.es/m/CA+hUKGKX9hFZrYA7rQzAMRE07L4hziCc-nO_b3taJpiuKyLLxg@mail.gmail.com 15 September 2019, 12:16:59 UTC
1c6b62a Noah Misch 14 September 2019, 02:34:06 UTC Replace xlc __fetch_and_add() with inline asm. PostgreSQL has been unusable when built with xlc 13 and newer, which are incompatible with our use of __fetch_and_add(). Back-patch to 9.5, which introduced pg_atomic_fetch_add_u32(). Reviewed by Tom Lane. Discussion: https://postgr.es/m/20190831071157.GA3251746@rfd.leadboat.com 14 September 2019, 02:34:18 UTC
5b5b0f7 Noah Misch 14 September 2019, 02:33:30 UTC Test pg_atomic_fetch_add_ with variable addend and 16-bit edge cases. Back-patch to 9.5, which introduced these functions. Reviewed by Tom Lane. Discussion: https://postgr.es/m/20190831071157.GA3251746@rfd.leadboat.com 14 September 2019, 02:33:46 UTC
96b5033 Alvaro Herrera 13 September 2019, 19:36:28 UTC logical decoding: process ASSIGNMENT during snapshot build Most WAL records are ignored in early SnapBuild snapshot build phases. But it's critical to process some of them, so that later messages have the correct transaction state after the snapshot is completely built; in particular, XLOG_XACT_ASSIGNMENT messages are critical in order for sub-transactions to be correctly assigned to their parent transactions, or at least one assert misbehaves, as reported by Ildar Musin. Diagnosed-by: Masahiko Sawada Author: Masahiko Sawada Discussion: https://postgr.es/m/CAONYFtOv+Er1p3WAuwUsy1zsCFrSYvpHLhapC_fMD-zNaRWxYg@mail.gmail.com 13 September 2019, 19:36:28 UTC
a0a40f6 Alvaro Herrera 13 September 2019, 19:26:55 UTC Fix under-parenthesized macro definitions Lack of parens in the definitions could cause a statement using these macros to have unexpected semantics. In current code no bug is apparent, but best to fix the definitions to avoid problems down the line. Reported-by: Tom Lane Discussion: https://postgr.es/m/19795.1568400476@sss.pgh.pa.us 13 September 2019, 19:26:55 UTC
da47e43 Alvaro Herrera 13 September 2019, 17:51:13 UTC Fix progress reporting of CLUSTER / VACUUM FULL The progress state was being clobbered once the first index completed being rebuilt, causing the final phases of the operation not show anything in the progress view. This was inadvertently broken in 03f9e5cba0ee, which added progress tracking for REINDEX. (The reason this bugfix is this small is that I had already noticed this problem when writing monitoring for CREATE INDEX, and had already worked around it, as can be seen in discussion starting at https://postgr.es/m/20190329150218.GA25010@alvherre.pgsql Fixing the problem is just a matter of fixing one place touched by the REINDEX monitoring.) Reported by: Álvaro Herrera Author: Álvaro Herrera Discussion: https://postgr.es/m/20190801184333.GA21369@alvherre.pgsql 13 September 2019, 17:51:13 UTC
6eb9b20 Alexander Korotkov 13 September 2019, 14:21:20 UTC Typo fixes for documentation Discussion: https://postgr.es/m/CAEkD-mDUZrRE%3Dk-FznEg4Ed2VdjpZCyHoyo%2Bp0%2B8KvHqR%3DpNVQ%40mail.gmail.com Author: Liudmila Mantrova, Alexander Lakhin Reviewed-by: Alexander Korotkov, Alvaro Herrera Backpatch-through: 12 13 September 2019, 14:22:49 UTC
9f77186 Alexander Korotkov 13 September 2019, 14:12:20 UTC Documentation improvements to jsonpath Besides cosmetic improvements it removes statement that operators necessary need to be separated from operands with spaces, which is not really true. Discussion: https://postgr.es/m/CAEkD-mDUZrRE%3Dk-FznEg4Ed2VdjpZCyHoyo%2Bp0%2B8KvHqR%3DpNVQ%40mail.gmail.com Author: Liudmila Mantrova, Alexander Lakhin Reviewed-by: Alexander Korotkov, Alvaro Herrera Backpatch-through: 12 13 September 2019, 14:22:44 UTC
3097a0d Peter Geoghegan 12 September 2019, 22:45:07 UTC Fix nbtree page split rmgr desc routine. Include newitemoff in rmgr desc output for nbtree page split records. In passing, correct an obsolete comment that claimed that newitemoff is only logged for _L variant nbtree page split WAL records. Both issues were oversights in commit 2c03216d831, which revamped the WAL format. Author: Peter Geoghegan Backpatch: 9.5-, where the WAL format was revamped. 12 September 2019, 22:45:07 UTC
5e9b18c Tom Lane 12 September 2019, 22:29:17 UTC Fix usage of whole-row variables in WCO and RLS policy expressions. Since WITH CHECK OPTION was introduced, ExecInitModifyTable has initialized WCO expressions with the wrong plan node as parent -- that is, it passed its input subplan not the ModifyTable node itself. Up to now we thought this was harmless, but bug #16006 from Vinay Banakar shows it's not: if the input node is a SubqueryScan then ExecInitWholeRowVar can get confused into doing the wrong thing. (The fact that ExecInitWholeRowVar contains such logic is certainly a horrid kluge that doesn't deserve to live, but figuring out another way to do that is a task for some other day.) Andres had already noticed the wrong-parent mistake and fixed it in commit 148e632c0, but not being aware of any user-visible consequences, he quite reasonably didn't back-patch. This patch is simply a back-patch of 148e632c0, plus addition of a test case based on bug #16006. I also added the test case to v12/HEAD, even though the bug is already fixed there. Back-patch to all supported branches. 9.4 lacks RLS policies so the new test case doesn't work there, but I'm pretty sure a test could be devised based on using a whole-row Var in a plain WITH CHECK OPTION condition. (I lack the cycles to do so myself, though.) Andres Freund and Tom Lane Discussion: https://postgr.es/m/16006-99290d2e4642cbd5@postgresql.org Discussion: https://postgr.es/m/20181205225213.hiwa3kgoxeybqcqv@alap3.anarazel.de 12 September 2019, 22:29:17 UTC
fef55c5 Amit Kapila 11 September 2019, 04:55:49 UTC Doc: Update PL/pgSQL sample function in plpgsql.sgml. The example used to explain 'Looping Through Query Results' uses pseudo-materialized views. Replace it with a more up-to-date example which does the same thing with actual materialized views, which have been available since PostgreSQL 9.3. In the passing, change '%' as format specifier instead of '%s' as is used in other examples in plpgsql.sgml. Reported-by: Ian Barwick Author: Ian Barwick Reviewed-by: Amit Kapila Backpatch-through: 9.4 Discussion: https://postgr.es/m/9a70d393-7904-4918-c97c-649f6d114b6a@2ndquadrant.com 12 September 2019, 07:58:53 UTC
dc92bf5 Michael Paquier 11 September 2019, 02:07:25 UTC Expand properly list of TAP tests used for prove in vcregress.pl Depending on the system used, t/*.pl may not be expanded into a list of tests which can be consumed by prove when attempting to run TAP tests on a given path. Fix that by using glob() directly in the script, to make sure that a complete list of tests is provided. This has not proved to be an issue with MSVC as the list was properly expanded, but it is on Linux with perl's system(). This is extracted from a larger patch. Author: Tom Lane Discussion: https://postgr.es/m/6628.1567958876@sss.pgh.pa.us Backpatch-through: 9.4 11 September 2019, 02:07:25 UTC
b101683 Tom Lane 10 September 2019, 16:04:57 UTC Don't drop NOTICE messages in isolation tests. For its entire existence, isolationtester.c has forced client_min_messages to WARNING, but that seems like a very poor choice of test design. It should be up to individual test scripts to manage whether they emit notices and to ensure that the results are stable. (There were no NOTICE messages in the original set of isolation tests, so this was certainly dead code when committed, but perhaps it was needed at some earlier point.) It's possible that the original motivation was due to platform-dependent variations in the timing of stdout vs. stderr output. That should be moot since commits 73bcb76b7/6eda3e9c2, but just in case, adjust isotesterNoticeProcessor to print to stdout not stderr. (stderr seems like the wrong thing anyway: it should be for error printouts not expected test output.) Back-patch of commit ebd499282 into v12. I'll separately push this into older branches, but this is as much change as v12 needs. Discussion: https://postgr.es/m/14616.1564251339@sss.pgh.pa.us Discussion: https://postgr.es/m/E1i7IqC-0000Uc-5H@gemulon.postgresql.org 10 September 2019, 16:04:57 UTC
97fb88e Tom Lane 10 September 2019, 02:53:51 UTC Fix isolationtester race condition for notices sent before blocking. If a test sends a notice just before blocking, it's possible on slow machines for isolationtester to detect the blocked state before it's consumed the notice. (For this to happen, the notice would have to arrive after isolationtester has waited for data for 10ms, so on fast/lightly-loaded machines it's hard to reproduce the failure.) But, if we have seen the backend as blocked, it's certainly already sent any notices it's going to send. Therefore, one more round of PQconsumeInput and PQisBusy should be enough to collect and process any such notices. Back-patch of 30717637c into v12. We're still discussing whether to back-patch this further and/or back-patch some other recent isolationtester fixes, but this much is provably necessary to make the test cases added by 27cc7cd2b stable in v12. Discussion: https://postgr.es/m/14616.1564251339@sss.pgh.pa.us Discussion: https://postgr.es/m/E1i7IqC-0000Uc-5H@gemulon.postgresql.org 10 September 2019, 02:53:51 UTC
84bb33c Tom Lane 09 September 2019, 20:24:29 UTC Stamp 12beta4. 09 September 2019, 20:24:29 UTC
5348e22 Tom Lane 09 September 2019, 18:21:40 UTC Be more careful about port selection in src/test/ldap/. Don't just assume that the next port is free; it might not be, or if we're really unlucky it might even be out of the TCP range. Do it honestly with two get_free_port() calls instead. This is surely a pretty low-probability problem, but I think it explains a buildfarm failure seen today, so let's fix it. Back-patch to v11 where this script was added. Discussion: https://postgr.es/m/25124.1568052346@sss.pgh.pa.us 09 September 2019, 18:21:47 UTC
9668b02 Andrew Dunstan 09 September 2019, 12:56:33 UTC Prevent msys2 conversion of "cmd /c" switch to a file path Modern versions of msys2 have changed the treatment of "cmd /c" so that the runtime will try to convert the switch to a native file path. This patch adds a setting to inhibit that behaviour. Discussion: https://postgr.es/m/3227042f-cfcc-745a-57dd-fb8c471f8ddf@2ndQuadrant.com Backpatch to all live branches. 09 September 2019, 13:02:39 UTC
7d49803 Andrew Dunstan 09 September 2019, 12:42:06 UTC Always skip recovery SysV shared memory tests on Windows These tests were disabled on git master in commit 8e5ce1c3f8. This does the same thing on the back branches. Discussion: https://postgr.es/m/a1c40fab-a38c-cb42-6879-125f834e837b@2ndQuadrant.com 09 September 2019, 12:43:16 UTC
3fb307b Andres Freund 09 September 2019, 12:21:30 UTC Reorder EPQ work, to fix rowmark related bugs and improve efficiency. In ad0bda5d24ea I changed the EvalPlanQual machinery to store substitution tuples in slot, instead of using plain HeapTuples. The main motivation for that was that using HeapTuples will be inefficient for future tableams. But it turns out that that conversion was buggy for non-locking rowmarks - the wrong tuple descriptor was used to create the slot. As a secondary issue 5db6df0c0 changed ExecLockRows() to begin EPQ earlier, to allow to fetch the locked rows directly into the EPQ slots, instead of having to copy tuples around. Unfortunately, as Tom complained, that forces some expensive initialization to happen earlier. As a third issue, the test coverage for EPQ was clearly insufficient. Fixing the first issue is unfortunately not trivial: Non-locked row marks were fetched at the start of EPQ, and we don't have the type information for the rowmarks available at that point. While we could change that, it's not easy. It might be worthwhile to change that at some point, but to fix this bug, it seems better to delay fetching non-locking rowmarks when they're actually needed, rather than eagerly. They're referenced at most once, and in cases where EPQ fails, might never be referenced. Fetching them when needed also increases locality a bit. To be able to fetch rowmarks during execution, rather than initialization, we need to be able to access the active EPQState, as that contains necessary data. To do so move EPQ related data from EState to EPQState, and, only for EStates creates as part of EPQ, reference the associated EPQState from EState. To fix the second issue, change EPQ initialization to allow use of EvalPlanQualSlot() to be used before EvalPlanQualBegin() (but obviously still requiring EvalPlanQualInit() to have been done). As these changes made struct EState harder to understand, e.g. by adding multiple EStates, significantly reorder the members, and add a lot more comments. Also add a few more EPQ tests, including one that fails for the first issue above. More is needed. Reported-By: yi huang Author: Andres Freund Reviewed-By: Tom Lane Discussion: https://postgr.es/m/CAHU7rYZo_C4ULsAx_LAj8az9zqgrD8WDd4hTegDTMM1LMqrBsg@mail.gmail.com https://postgr.es/m/24530.1562686693@sss.pgh.pa.us Backpatch: 12-, where the EPQ changes were introduced 09 September 2019, 12:21:30 UTC
c6ce5f7 Alexander Korotkov 09 September 2019, 10:50:12 UTC Fix handling of non-key columns get_index_column_opclass() f2e40380 introduces support of non-key attributes in GiST indexes. Then if get_index_column_opclass() is asked by gistproperty() to get an opclass of non-key column, it returns garbage past oidvector value. This commit fixes that by making get_index_column_opclass() return InvalidOid in this case. Discussion: https://postgr.es/m/20190902231948.GA5343%40alvherre.pgsql Author: Nikita Glukhov, Alexander Korotkov Backpatch-through: 12 09 September 2019, 11:02:40 UTC
55a808c Peter Eisentraut 09 September 2019, 09:34:06 UTC Translation updates Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 2808de890d4be52a0a82fb3bd84ea7998c6f5101 09 September 2019, 09:34:06 UTC
ef48a05 Peter Eisentraut 09 September 2019, 08:30:22 UTC Improve new AND CHAIN tests Tweak the tests so that we're not just testing the default setting of transaction_read_only. Reported-by: fn ln <emuser20140816@gmail.com> 09 September 2019, 08:31:35 UTC
2403e54 Tom Lane 08 September 2019, 21:00:29 UTC Fix RelationIdGetRelation calls that weren't bothering with error checks. Some of these are quite old, but that doesn't make them not bugs. We'd rather report a failure via elog than SIGSEGV. While at it, uniformly spell the error check as !RelationIsValid(rel) rather than a bare rel == NULL test. The machine code is the same but it seems better to be consistent. Coverity complained about this today, not sure why, because the mistake is in fact old. 08 September 2019, 21:00:52 UTC
e6af7b3 Alexander Korotkov 08 September 2019, 18:13:40 UTC Fix handling of NULL distances in KNN-GiST In order to implement NULL LAST semantic GiST previously assumed distance to the NULL value to be Inf. However, our distance functions can return Inf and NaN for non-null values. In such cases, NULL LAST semantic appears to be broken. This commit fixes that by introducing separate array of null flags for distances. Backpatch to all supported versions. Discussion: https://postgr.es/m/CAPpHfdsNvNdA0DBS%2BwMpFrgwT6C3-q50sFVGLSiuWnV3FqOJuQ%40mail.gmail.com Author: Alexander Korotkov Backpatch-through: 9.4 08 September 2019, 18:17:37 UTC
bc67f41 Alexander Korotkov 08 September 2019, 18:07:30 UTC Fix handling Inf and Nan values in GiST pairing heap comparator Previously plain float comparison was used in GiST pairing heap. Such comparison doesn't provide proper ordering for value sets containing Inf and Nan values. This commit fixes that by usage of float8_cmp_internal(). Note, there is remaining problem with NULL distances, which are represented as Inf in pairing heap. It would be fixes in subsequent commit. Backpatch to all supported versions. Reported-by: Andrey Borodin Discussion: https://postgr.es/m/CAPpHfdsNvNdA0DBS%2BwMpFrgwT6C3-q50sFVGLSiuWnV3FqOJuQ%40mail.gmail.com Author: Alexander Korotkov Reviewed-by: Heikki Linnakangas Backpatch-through: 9.4 08 September 2019, 18:17:31 UTC
b6d72dd Peter Eisentraut 08 September 2019, 14:11:21 UTC Fix behavior of AND CHAIN outside of explicit transaction blocks When using COMMIT AND CHAIN or ROLLBACK AND CHAIN not in an explicit transaction block, the previous implementation would leave a transaction block active in the ROLLBACK case but not the COMMIT case. To fix for now, error out when using these commands not in an explicit transaction block. This restriction could be lifted if a sensible definition and implementation is found. Bug: #15977 Author: fn ln <emuser20140816@gmail.com> Reviewed-by: Fabien COELHO <coelho@cri.ensmp.fr> 08 September 2019, 14:22:51 UTC
4229104 Peter Eisentraut 08 September 2019, 09:10:49 UTC doc: effective -> efficient 08 September 2019, 09:11:24 UTC
eecd7c3 Peter Eisentraut 08 September 2019, 08:26:35 UTC doc: Clean up title case use Note: Following existing practice, titles of formalpara and step are not titlecased. 08 September 2019, 08:27:16 UTC
121e3ce Tom Lane 07 September 2019, 23:03:11 UTC Avoid using INFO elevel for what are fundamentally debug messages. Commit 6f6b99d13 stuck an INFO message into the fast path for checking partition constraints, for no very good reason except that it made it easy for the regression tests to verify that that path was taken. Assorted later patches did likewise, increasing the unsuppressable-chatter level from ALTER TABLE even more. This isn't good for the user experience, so let's drop these messages down to DEBUG1 where they belong. So as not to have a loss of test coverage, create a TAP test that runs the relevant queries with client_min_messages = DEBUG1 and greps for the expected messages. This testing method is a bit brute-force --- in particular, it duplicates the execution of a fair amount of the core create_table and alter_table tests. We experimented with other solutions, but running any significant amount of standard testing with client_min_messages = DEBUG1 seems to have a lot of output-stability pitfalls, cf commits bbb96c370 and 5655565c0. Possibly at some point we'll look into whether we can reduce the amount of test duplication. Backpatch into v12, because some of these messages are new in v12 and we don't really want to ship it that way. Sergei Kornilov Discussion: https://postgr.es/m/81911511895540@web58j.yandex.ru Discussion: https://postgr.es/m/4859321552643736@myt5-02b80404fd9e.qloud-c.yandex.net 07 September 2019, 23:03:11 UTC
b6a4d04 Tom Lane 07 September 2019, 15:21:24 UTC Doc: make an editing pass over the v12 release notes. Copy-edit or rewrite some items, add some items that I thought deserved documenting, remove some others that didn't (notably, I'm not on board with documenting documentation changes), fix some poorly-pointed links, move some items to other sections, etc etc. 07 September 2019, 15:21:42 UTC
2552c78 Peter Eisentraut 06 September 2019, 14:12:28 UTC Message style fixes 06 September 2019, 20:53:16 UTC
ce35a26 Peter Eisentraut 06 September 2019, 20:19:53 UTC doc: Fix awkward markup 06 September 2019, 20:21:03 UTC
69116b7 Peter Eisentraut 06 September 2019, 20:16:58 UTC doc: Postgres -> PostgreSQL 06 September 2019, 20:17:58 UTC
700a1ac Tom Lane 06 September 2019, 19:15:38 UTC Update v12 release notes through today, and add major-enhancements list. I still want to review the rest of the notes, but this seems like the minimum work required to prepare for beta4. Major-enhancements text, and a couple of other fixes, from Jonathan Katz (with minor copy-editing by me). 06 September 2019, 19:15:38 UTC
d1da0bc Tom Lane 06 September 2019, 15:24:36 UTC Doc: tweak installation doc edits made by commit 76c2af926. We don't consider that building with MinGW is deprecated, so adjust some places that gave that impression. Per discussion with Peter Eisentraut. Discussion: https://postgr.es/m/4a023388-8652-fea0-a0b4-35ad5e734e9a@2ndquadrant.com 06 September 2019, 16:10:29 UTC
ce5542d Robert Haas 06 September 2019, 12:22:32 UTC When performing a base backup, check for read errors. The old code didn't differentiate between a read error and a concurrent truncation. fread reports both of these by returning 0; you have to use feof() or ferror() to distinguish between them, which this code did not do. It might be a better idea to use read() rather than fread() here, so that we can display a less-generic error message, but I'm not sure that would qualify as a back-patchable bug fix, so just do this much for now. Jeevan Chalke, reviewed by Jeevan Ladhe and by me. Discussion: http://postgr.es/m/CA+TgmobG4ywMzL5oQq2a8YKp8x2p3p1LOMMcGqpS7aekT9+ETA@mail.gmail.com 06 September 2019, 12:49:56 UTC
d57a931 Peter Eisentraut 06 September 2019, 07:15:35 UTC libpq: ccache -> credential cache The term "ccache" is overloaded. Let's be more clear, in case someone other than a Kerberos wizard has to read this code. 06 September 2019, 07:18:31 UTC
7aa815a Fujii Masao 06 September 2019, 05:27:25 UTC Make pg_promote() detect postmaster death while waiting for promotion to end. Previously even if postmaster died and WaitLatch() woke up with that event while pg_promote() was waiting for the standby promotion to finish, pg_promote() did nothing special and kept waiting until timeout occurred. This could cause a busy loop. This patch make pg_promote() return false immediately when postmaster dies, to avoid such a busy loop. Back-patch to v12 where pg_promote() was added. Author: Fujii Masao Reviewed-by: Michael Paquier Discussion: https://postgr.es/m/CAHGQGwEs9ROgSp+QF+YdDU+xP8W=CY1k-_Ov-d_Z3JY+to3eXA@mail.gmail.com 06 September 2019, 05:28:25 UTC
4c3e750 Michael Paquier 04 September 2019, 06:46:45 UTC Fix thinko when ending progress report for a backend The logic ending progress reporting for a backend entry introduced by b6fb647 causes callers of pgstat_progress_end_command() to do some extra work when track_activities is enabled as the process fields are reset in the backend entry even if no command were started for reporting. This resets the fields only if a command is registered for progress reporting, and only if track_activities is enabled. Author: Masahiho Sawada Discussion: https://postgr.es/m/CAD21AoCry_vJ0E-m5oxJXGL3pnos-xYGCzF95rK5Bbi3Uf-rpA@mail.gmail.com Backpatch-through: 9.6 04 September 2019, 06:46:45 UTC
64eb426 Michael Paquier 04 September 2019, 04:23:41 UTC Delay fsyncs of pg_basebackup until the end of backup Since the addition of fsync requests in bc34223 to make base backup data consistent on disk once pg_basebackup finishes, each tablespace tar file is individually flushed once completed, with an additional flush of the parent directory when the base backup finishes. While holding a connection to the server, a fsync request taking a long time may cause a failure of the base backup, which is annoying for any integration. A recent example of breakage can involve tcp_user_timeout, but wal_sender_timeout can cause similar problems. While reviewing the code, there was a second issue causing too many fsync requests to be done for the same WAL data. As recursive fsyncs are done at the end of the backup for both the plain and tar formats from the base target directory where everything is written, it is fine to disable fsyncs when fetching or streaming WAL. Reported-by: Ryohei Takahashi Author: Michael Paquier Reviewed-by: Ryohei Takahashi Discussion: https://postgr.es/m/OSBPR01MB4550DAE2F8C9502894A45AAB82BE0@OSBPR01MB4550.jpnprd01.prod.outlook.com Backpatch-through: 10 04 September 2019, 04:23:41 UTC
7368719 Peter Eisentraut 03 September 2019, 12:25:26 UTC Clarify pg_dump documentation Clarify in the help output and documentation that -n, -t etc. take a "pattern" rather than a "schema" or "table" etc. This was especially confusing now that the new pg_dumpall --exclude-database option was documented with "pattern" and the others not, even though they all behave the same. Discussion: https://www.postgresql.org/message-id/flat/b85f3fa1-b350-38d1-1893-4f7911bd7310%402ndquadrant.com 03 September 2019, 12:25:47 UTC
3e20b7f Peter Eisentraut 03 September 2019, 06:26:55 UTC pg_checksums: Handle read and write returns correctly The read() return was not checking for errors, the write() return was not checking for short writes. Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/flat/5de61b6b-8be9-7771-0048-860328efe027%402ndquadrant.com 03 September 2019, 06:34:59 UTC
6ef1216 Peter Eisentraut 03 September 2019, 06:26:55 UTC Better error messages for short reads/writes in SLRU This avoids getting a Could not read from file ...: Success. for a short read or write (since errno is not set in that case). Instead, report a more specific error messages. Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/flat/5de61b6b-8be9-7771-0048-860328efe027%402ndquadrant.com 03 September 2019, 06:34:59 UTC
5380719 Michael Paquier 03 September 2019, 03:31:03 UTC Fix memory leak with lower, upper and initcap with ICU-provided collations The leak happens in str_tolower, str_toupper and str_initcap, which are used in several places including their equivalent SQL-level functions, and can only be triggered when using an ICU-provided collation when converting the input string. b615920 fixed a similar leak. Backpatch down 10 where ICU collations have been introduced. Author: Konstantin Knizhnik Discussion: https://postgr.es/m/94c0ad0a-cbc2-e4a3-7829-2bdeaf9146db@postgrespro.ru Backpatch-through: 10 03 September 2019, 03:31:03 UTC
aad0926 Tom Lane 02 September 2019, 20:10:37 UTC Avoid touching replica identity index in ExtractReplicaIdentity(). In what seems like a fit of misplaced optimization, ExtractReplicaIdentity() accessed the relation's replica-identity index without taking any lock on it. Usually, the surrounding query already holds some lock so this is safe enough ... but in the case of a previously-planned delete, there might be no existing lock. Given a suitable test case, this is exposed in v12 and HEAD by an assertion added by commit b04aeb0a0. The whole thing's rather poorly thought out anyway; rather than looking directly at the index, we should use the index-attributes bitmap that's held by the parent table's relcache entry, as the caller functions do. This is more consistent and likely a bit faster, since it avoids a cache lookup. Hence, change to doing it that way. While at it, rather than blithely assuming that the identity columns are non-null (with catastrophic results if that's wrong), add assertion checks that they aren't null. Possibly those should be actual test-and-elog, but I'll leave it like this for now. In principle, this is a bug that's been there since this code was introduced (in 9.4). In practice, the risk seems quite low, since we do have a lock on the index's parent table, so concurrent changes to the index's catalog entries seem unlikely. Given the precedent that commit 9c703c169 wasn't back-patched, I won't risk back-patching this further than v12. Per report from Hadi Moshayedi. Discussion: https://postgr.es/m/CAK=1=Wrek44Ese1V7LjKiQS-Nd-5LgLi_5_CskGbpggKEf3tKQ@mail.gmail.com 02 September 2019, 20:10:37 UTC
90433c3 Tom Lane 02 September 2019, 18:02:45 UTC Handle corner cases correctly in psql's reconnection logic. After an unexpected connection loss and successful reconnection, psql neglected to resynchronize its internal state about the server, such as server version. Ordinarily we'd be reconnecting to the same server and so this isn't really necessary, but there are scenarios where we do need to update --- one example is where we have a list of possible connection targets and they're not all alike. Define "resynchronize" as including connection_warnings(), so that this case acts the same as \connect. This seems useful; for example, if the server version did change, the user might wish to know that. An attuned user might also notice that the new connection isn't SSL-encrypted, for example, though this approach isn't especially in-your-face about such changes. Although this part is a behavioral change, it only affects interactive sessions, so it should not break any applications. Also, in do_connect, make sure that we desynchronize correctly when abandoning an old connection in non-interactive mode. These problems evidently are the result of people patching only one of the two places where psql deals with connection changes, so insert some cross-referencing comments in hopes of forestalling future bugs of the same ilk. Lastly, in Windows builds, issue codepage mismatch warnings only at startup, not during reconnections. psql's codepage can't change during a reconnect, so complaining about it again seems like useless noise. Peter Billen and Tom Lane. Back-patch to all supported branches. Discussion: https://postgr.es/m/CAMTXbE8e6U=EBQfNSe01Ej17CBStGiudMAGSOPaw-ALxM-5jXg@mail.gmail.com 02 September 2019, 18:02:45 UTC
5eec908 Tom Lane 31 August 2019, 18:05:32 UTC Doc: describe the "options" allowed in an ECPG connection target string. These have been there a long time, but their format was never explained in the docs. Per complaint from Yusuke Egashira. Discussion: https://postgr.es/m/848B1649C8A6274AA527C4472CA11EDD5FC70CBE@G01JPEXMBYT02 31 August 2019, 18:05:32 UTC
3592098 Tom Lane 30 August 2019, 17:02:35 UTC Doc: remove some long-obsolete information from installation.sgml. Section 16.2 pointed to platform-specific FAQ files that we removed way back in 8.4. Section 16.7 contained a bunch of information about AIX and HPUX bugs that were squashed decades ago, plus discussions of old compiler versions that are certainly moot now that we require C99 support. Since we're obviously not maintaining this stuff carefully, just remove it. The HPUX sub-section seems like it can go away entirely, since everything it said that was still applicable was redundant with material elsewhere in the chapter. In passing, I couldn't resist the temptation to do a small amount of copy-editing on nearby text. Back-patch to v12, since this stuff is surely obsolete in any branch that requires C99. Discussion: https://postgr.es/m/15538.1567042743@sss.pgh.pa.us 30 August 2019, 17:02:35 UTC
8ff5de1 Etsuro Fujita 29 August 2019, 09:45:01 UTC Fix typos in regression test comments. 29 August 2019, 09:45:01 UTC
6b7819a Heikki Linnakangas 28 August 2019, 09:55:33 UTC Fix overflow check and comment in GIN posting list encoding. The comment did not match what the code actually did for integers with the 43rd bit set. You get an integer like that, if you have a posting list with two adjacent TIDs that are more than 2^31 blocks apart. According to the comment, we would store that in 6 bytes, with no continuation bit on the 6th byte, but in reality, the code encodes it using 7 bytes, with a continuation bit on the 6th byte as normal. The decoding routine also handled these 7-byte integers correctly, except for an overflow check that assumed that one integer needs at most 6 bytes. Fix the overflow check, and fix the comment to match what the code actually does. Also fix the comment that claimed that there are 17 unused bits in the 64-bit representation of an item pointer. In reality, there are 64-32-11=21. Fitting any item pointer into max 6 bytes was an important property when this was written, because in the old pre-9.4 format, item pointers were stored as plain arrays, with 6 bytes for every item pointer. The maximum of 6 bytes per integer in the new format guaranteed that we could convert any page from the old format to the new format after upgrade, so that the new format was never larger than the old format. But we hardly need to worry about that anymore, and running into that problem during upgrade, where an item pointer is expanded from 6 to 7 bytes such that the data doesn't fit on a page anymore, is implausible in practice anyway. Backpatch to all supported versions. This also includes a little test module to test these large distances between item pointers, without requiring a 16 TB table. It is not backpatched, I'm including it more for the benefit of future development of new posting list formats. Discussion: https://www.postgresql.org/message-id/33bfc20a-5c86-f50c-f5a5-58e9925d05ff%40iki.fi Reviewed-by: Masahiko Sawada, Alexander Korotkov 28 August 2019, 09:56:03 UTC
8cc6016 Thomas Munro 28 August 2019, 01:37:03 UTC Avoid catalog lookups in RelationAllowsEarlyPruning(). RelationAllowsEarlyPruning() performed a catalog scan, but is used in two contexts where that was a bad idea: 1. In heap_page_prune_opt(), which runs very frequently in some large scans. This caused major performance problems in a field report that was easy to reproduce. 2. In TestForOldSnapshot(), which runs while we hold a buffer content lock. It's not clear if this was guaranteed to be free of buffer deadlock risk. The check was introduced in commit 2cc41acd8 and defended against a real problem: 9.6's hash indexes have no page LSN and so we can't allow early pruning (ie the snapshot-too-old feature). We can remove the check from all later releases though: hash indexes are now logged, and there is no way to create UNLOGGED indexes on regular logged tables. If a future release allows such a combination, it might need to put a similar check in place, but it'll need some more thought. Back-patch to 10. Author: Thomas Munro Reviewed-by: Tom Lane, who spotted the second problem Discussion: https://postgr.es/m/CA%2BhUKGKT8oTkp5jw_U4p0S-7UG9zsvtw_M47Y285bER6a2gD%2Bg%40mail.gmail.com Discussion: https://postgr.es/m/CAA4eK1%2BWy%2BN4eE5zPm765h68LrkWc3Biu_8rzzi%2BOYX4j%2BiHRw%40mail.gmail.com 28 August 2019, 04:18:39 UTC
e96f524 Michael Paquier 28 August 2019, 02:48:15 UTC Disable timeouts when running pg_rewind with online source cluster In this case, the transfer uses a libpq connection, which is subject to the timeout parameters set at system level, and this can make the rewind operation suddenly canceled which is not good for automation. One workaround to such issues would be to use PGOPTIONS to enforce the wanted timeout parameters, but that's annoying, and for example pg_dump, which can run potentially long-running queries disables all types of timeouts. lock_timeout and statement_timeout are the ones which can cause problems now. Note that pg_rewind does not use transactions, so disabling idle_in_transaction_session_timeout is optional, but it feels safer to do so for the future. This is back-patched down to 9.5. idle_in_transaction_session_timeout is only present since 9.6. Author: Alexander Kukushkin Discussion: https://postgr.es/m/CAFh8B=krcVXksxiwVQh1SoY+ziJ-JC=6FcuoBL3yce_40Es5_g@mail.gmail.com Backpatch-through: 9.5 28 August 2019, 02:48:15 UTC
11f6271 Tom Lane 27 August 2019, 22:03:09 UTC Doc: improve documentation of pg_signal_backend default role. Give it an explanatory para like the other default roles have. Don't imply that it can send any signal whatever. In passing, reorder the table entries and explanatory paras for the default roles into some semblance of consistency. Ian Barwick, tweaked a bit by me. Discussion: https://postgr.es/m/89907e32-76f3-7282-a89c-ea19c722fe5d@2ndquadrant.com 27 August 2019, 22:03:09 UTC
7570df0 Tom Lane 27 August 2019, 21:24:13 UTC Improve what pg_strsignal prints if we haven't got strsignal(3). Turns out that returning "unrecognized signal" is confusing. Make it explicit that the platform lacks any support for signal names. (At least of the machines in the buildfarm, only HPUX lacks it.) Back-patch to v12 where we invented this function. Discussion: https://postgr.es/m/3067.1566870481@sss.pgh.pa.us 27 August 2019, 21:24:30 UTC
c0222c2 Tom Lane 27 August 2019, 20:37:22 UTC Doc: clarify behavior of standard aggregates for null inputs. Section 4.2.7 says that unless otherwise specified, built-in aggregates ignore rows in which any input is null. This is not true of the JSON aggregates, but it wasn't documented. Fix that. Of the other entries in table 9.55, some were explicit about ignoring nulls, and some weren't; for consistency and self-contained-ness, make them all say it explicitly. Per bug #15884 from Tim Möhlmann. Back-patch to all supported branches. Discussion: https://postgr.es/m/15884-c32d848f787fcae3@postgresql.org 27 August 2019, 20:37:22 UTC
1510339 Tom Lane 27 August 2019, 18:44:26 UTC Reject empty names and recursion in config-file include directives. An empty file name or subdirectory name leads join_path_components() to just produce the parent directory name, which leads to weird failures or recursive inclusions. Let's throw a specific error for that. It takes only slightly more code to detect all-blank names, so do so. Also, detect direct recursion, ie a file calling itself. As coded this will also detect recursion via "include_dir '.'", which is perhaps more likely than explicitly including the file itself. Detecting indirect recursion would require API changes for guc-file.l functions, which seems not worth it since extensions might call them. The nesting depth limit will catch such cases eventually, just not with such an on-point error message. In passing, adjust the example usages in postgresql.conf.sample to perhaps eliminate the problem at the source: there's no reason for the examples to suggest that an empty value is valid. Per a trouble report from Brent Bates. Back-patch to 9.5; the issue is old, but the code in 9.4 is enough different that the patch doesn't apply easily, and it doesn't seem worth the trouble to fix there. Ian Barwick and Tom Lane Discussion: https://postgr.es/m/8c8bcbca-3bd9-dc6e-8986-04a5abdef142@2ndquadrant.com 27 August 2019, 18:44:26 UTC
b783a38 Michael Paquier 27 August 2019, 00:11:38 UTC Fix failure of --jobs with vacuumdb on Windows FD_SETSIZE needs to be declared before winsock2.h, or it is possible to run into buffer overflow issues when using --jobs. This is similar to pgbench's solution done in a23c641. This has been introduced by 71d84ef, and older versions have been using the default value of FD_SETSIZE, defined at 64. Per buildfarm member jacana, but this impacts all Windows animals running the TAP tests. I have reproduced the failure locally to check the patch. Author: Michael Paquier Reviewed-by: Andrew Dunstan Discussion: https://postgr.es/m/20190826054000.GE7005@paquier.xyz Backpatch-through: 9.5 27 August 2019, 00:11:38 UTC
6bdd9fb Peter Eisentraut 26 August 2019, 17:04:35 UTC Fix gettext triggers specification In cc8d41511721d25d557fc02a46c053c0a602fed0, the arguments of warn_or_exit_horribly() were changed but this was not updated. 26 August 2019, 17:04:35 UTC
97205d0 Andrew Dunstan 26 August 2019, 12:11:27 UTC Adjust to latest Msys2 kernel release number Previously 'uname -r' on Msys2 reported a kernele release starting with 2. The latest version starts with 3. In commit 1638623f we specifically looked for one starting with 2. This is now changed to look for any digit between 2 and 9. backpatch to release 10. 26 August 2019, 12:19:11 UTC
67d5af3 Andrew Dunstan 26 August 2019, 11:44:34 UTC Treat MINGW and MSYS the same in pg_upgrade test script On msys2, 'uname -s' reports a string starting MSYS instead on MINGW as happens on msys1. Treat these both the same way. This reverts 608a710195a4b in favor of a more general solution. Backpatch to all live branches. 26 August 2019, 11:45:45 UTC
63fc3b1 Michael Paquier 26 August 2019, 02:14:24 UTC Fix error handling of vacuumdb when running out of fds When trying to use a high number of jobs, vacuumdb has only checked for a maximum number of jobs used, causing confusing failures when running out of file descriptors when the jobs open connections to Postgres. This commit changes the error handling so as we do not check anymore for a maximum number of allowed jobs when parsing the option value with FD_SETSIZE, but check instead if a file descriptor is within the supported range when opening the connections for the jobs so as this is detected at the earliest time possible. Also, improve the error message to give a hint about the number of jobs recommended, using a wording given by the reviewers of the patch. Reported-by: Andres Freund Author: Michael Paquier Reviewed-by: Andres Freund, Álvaro Herrera, Tom Lane Discussion: https://postgr.es/m/20190818001858.ho3ev4z57fqhs7a5@alap3.anarazel.de Backpatch-through: 9.5 26 August 2019, 02:14:24 UTC
3633825 Tom Lane 25 August 2019, 19:04:04 UTC Avoid platform-specific null pointer dereference in psql. POSIX permits getopt() to advance optind beyond argc when the last argv entry is an option that requires an argument and hasn't got one. It seems that no major platforms actually do that, but musl does, so that something like "psql -f" would crash with that libc. Add a check that optind is in range before trying to look at the possibly-bogus option. Report and fix by Quentin Rameau. Back-patch to all supported branches. Discussion: https://postgr.es/m/20190825100617.GA6087@fifth.space 25 August 2019, 19:04:04 UTC
cd714b3 Tom Lane 25 August 2019, 16:14:50 UTC Back off output precision in circle.sql regression test. We were setting extra_float_digits = 0 to avoid platform-dependent output in this test, but that's still able to expose platform-specific roundoff behavior in some new test cases added by commit a3d284485, as reported by Peter Eisentraut. Reduce it to -1 to hide that. (Over in geometry.sql, we're using -3, which is an ancient decision dating to 337f73b1b. I wonder whether that's overkill now. But there's probably little value in trying to change it.) Back-patch to v12 where a3d284485 came in; there's no evidence that we have any platform-dependent issues here before that. Discussion: https://postgr.es/m/15551268-e224-aa46-084a-124b64095ee3@2ndquadrant.com 25 August 2019, 16:14:50 UTC
54ff1c3 Thomas Munro 25 August 2019, 01:54:48 UTC Don't rely on llvm::make_unique. Bleeding-edge LLVM has stopped supplying replacements for various C++14 library features, for people on older C++ versions. Since we're not ready to require C++14 yet, just use plain old new instead of make_unique. As revealed by buildfarm animal seawasp. Back-patch to 11. Reviewed-by: Andres Freund Discussion: https://postgr.es/m/CA%2BhUKGJWG7unNqmkxg7nC5o3o-0p2XP6co4r%3D9epqYMm8UY4Mw%40mail.gmail.com 25 August 2019, 02:46:29 UTC
back to top