summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-09-28Improve stability of partition_prune regression test.Tom Lane
This test already knew that, to get stable test output, it had to hide "loops" counts in EXPLAIN ANALYZE results. But that's not nearly enough: if we get a smaller number of workers than we planned for, then the "Workers Launched" number will change, and so will all the rows and loops counts up to the Gather node. This has resulted in repeated failures in the buildfarm, so adjust the test to filter out all these counts. (Really, we wouldn't bother with EXPLAIN ANALYZE at all here, except that currently the only way to verify that executor-time pruning has happened is to look for '(never executed)' annotations. Those are stable and needn't be filtered out.) Back-patch to v11 where the test was introduced. Discussion: https://postgr.es/m/11952.1569536725@sss.pgh.pa.us
2019-09-27ANALYZE a_star and its children to avoid plan instability in tests.Tom Lane
We've noted certain EXPLAIN queries on these tables occasionally showing unexpected plan choices. This seems to happen because VACUUM sometimes fails to update relpages/reltuples for one of these single-page tables, due to bgwriter or checkpointer holding a pin on the lone page at just the wrong time. To ensure those values get set, insert explicit ANALYZE operations on these tables after we finish populating them. This doesn't seem to affect any other test cases, so it's a usable fix. Back-patch to v12. In principle the issue exists further back, but we have not seen it before v12, so I won't risk back-patching further. Discussion: https://postgr.es/m/24480.1569518042@sss.pgh.pa.us
2019-09-27Doc: clean up markup for jsonb_set and related functions.Tom Lane
The markup for optional parameters was neither correct nor consistent. In passing, fix a spelling mistake. Per report from Alex Macy. Some of these mistakes are old, so back-patch as appropriate. Discussion: https://postgr.es/m/156953522258.1204.12736099368284950578@wrigleys.postgresql.org
2019-09-27doc: Add timeline as valid recovery target in standby.signal documentationPeter Eisentraut
The documentation states that no target settings will be used when standby.signal is present, but this is not quite the case since recovery_target_timeline is a valid recovery target for a standby. Update the documentation with this exception. Author: David Steele <david@pgmasters.net> Discussion: https://www.postgresql.org/message-id/flat/e445616d-023e-a268-8aa1-67b8b335340c%40pgmasters.net
2019-09-27Add tab completion for EXPLAIN (SETTINGS) in psqlMichael Paquier
Author: Justin Pryzby Reviewed-by: Tatsuro Yamada Discussion: https://postgr.es/m/20190927022051.GC24334@telsasoft.com Backpatch-through: 12
2019-09-27Fix oversight in commit 4429f6a9e3e12bb4af6e3677fbc78cd80f160252.Amit Kapila
The test name and the following test cases suggest the index created should be hash index, but it forgot to add 'using hash' in the test case. This in itself won't improve code coverage as there were some other tests which were covering the corresponding code. However, it is better if the added tests serve their actual purpose. Reported-by: Paul A Jungwirth Author: Paul A Jungwirth Reviewed-by: Mahendra Singh Backpatch-through: 9.4 Discussion: https://postgr.es/m/CA+renyV=Us-5XfMC25bNp-uWSj39XgHHmGE9Rh2cQKMegSj52g@mail.gmail.com
2019-09-26doc: Fix whitespace in markupPeter Eisentraut
2019-09-26doc: Format example JSON data betterPeter Eisentraut
2019-09-26doc: Update a confusing sentence about SQL/JSONPeter Eisentraut
Author: Liudmila Mantrova <l.mantrova@postgrespro.ru> Reported-by: Jeff Janes <jeff.janes@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CAMkU%3D1wP-SO4KpiLxHJuPezTJCmK%3DJqefLXrr3eXFO7Qku%2BtMg%40mail.gmail.com
2019-09-26doc: Update note about source code formattingPeter Eisentraut
Update the note about why not to use // comments, even though it's now technically supported. The note about variable declarations was dropped here because it's addressed more properly later in the chapter. Discussion: https://www.postgresql.org/message-id/flat/156924954640.1117.6309209869705522549%40wrigleys.postgresql.org
2019-09-26doc: Reorder JSON functions documentationPeter Eisentraut
Put the description of the SQL/JSON path language after the description of the general JSON functions and operators, instead of before. Discussion: https://www.postgresql.org/message-id/16968.1569189812@sss.pgh.pa.us
2019-09-25Fix handling of GENERATED columns in CREATE TABLE LIKE INCLUDING DEFAULTS.Tom Lane
LIKE INCLUDING DEFAULTS tried to copy the attrdef expression without copying the state of the attgenerated column. This is in fact wrong, because GENERATED and DEFAULT expressions are not the same kind of animal; one can contain Vars and the other not. We *must* copy attgenerated when we're copying the attrdef expression. Rearrange the if-tests so that the expression is copied only when the correct one of INCLUDING DEFAULTS and INCLUDING GENERATED has been specified. Per private report from Manuel Rigger. Tom Lane and Peter Eisentraut
2019-09-25Doc: Fix example related to partition pruningMichael Paquier
Append node has been removed in v12 when there would be only one subnode under it. Author: Amit Langote Discussion: https://postgr.es/m/CA+HiwqHhS62w8zUFXF4NBjvMboCXYnD-jWoWp-tfo2aHvP3Gxg@mail.gmail.com Backpatch-through: 12
2019-09-25Fix failure with lock mode used for custom relation optionsMichael Paquier
In-core relation options can use a custom lock mode since 47167b7, that has lowered the lock available for some autovacuum parameters. However it forgot to consider custom relation options. This causes failures with ALTER TABLE SET when changing a custom relation option, as its lock is not defined. The existing APIs to define a custom reloption does not allow to define a custom lock mode, so enforce its initialization to AccessExclusiveMode which should be safe enough in all cases. An upcoming patch will extend the existing APIs to allow a custom lock mode to be defined. The problem can be reproduced with bloom indexes, so add a test there. Reported-by: Nikolay Sharplov Analyzed-by: Thomas Munro, Michael Paquier Author: Michael Paquier Reviewed-by: Kuntal Ghosh Discussion: https://postgr.es/m/20190920013831.GD1844@paquier.xyz Backpatch-through: 9.6
2019-09-25Fix bug in pairingheap_SpGistSearchItem_cmp()Alexander Korotkov
Our item contains only so->numberOfNonNullOrderBys of distances. Reflect that in the loop upper bound. Discussion: https://postgr.es/m/53536807-784c-e029-6e92-6da802ab8d60%40postgrespro.ru Author: Nikita Glukhov Backpatch-through: 12
2019-09-23Stamp 12rc1.REL_12_RC1Tom Lane
2019-09-23Doc: more contributor name cleanup.Tom Lane
Further adjust Japanese names, per advice from Etsuro Fujita. Discussion: https://postgr.es/m/CAPmGK15XT8eCwn1j3tB3CnOn2q6ksHNKwKjDrEcca5ZEfG0tng@mail.gmail.com
2019-09-23Doc: clarify handling of duplicate elements in array containment tests.Tom Lane
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
2019-09-23Doc: proofreading for v12 release notes.Tom Lane
Mostly markup improvements, with a couple of grammar fixes. Liudmila Mantrova Discussion: https://postgr.es/m/CAEkD-mDxVV1Hrxzo3-hPaS5b1s-+Gin+9Cbu2eMBqRovRVjC0w@mail.gmail.com
2019-09-23Doc: clean up some issues with spellings of contributor names.Tom Lane
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
2019-09-23Translation updatesPeter Eisentraut
Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 8a42b829ebeb8b22db0e3258ec02137f8840b960
2019-09-23Message style fixesPeter Eisentraut
2019-09-23NLS: Fix backend gettext triggersPeter Eisentraut
The backend also needs to pull in translations from the frontend pg_log_*() functions, since some files in src/common/ use those.
2019-09-22Fix failure to zero-pad the result of bitshiftright().Tom Lane
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
2019-09-22Fix typo in tts_virtual_copyslot.Tom Lane
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
2019-09-21Remove removed file from nls.mkPeter Eisentraut
part of revert "Add DECLARE STATEMENT support to ECPG."
2019-09-21Update list of acknowledgments in release notesPeter Eisentraut
current through 25f9368304e41c8837f59e94b161f07ac4c7d622
2019-09-21Straighten out leakproofness markings on text comparison functions.Tom Lane
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
2019-09-21Fix up handling of nondeterministic collations with pattern_ops opclasses.Tom Lane
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
2019-09-21Doc: updates for v12 release notes.Tom Lane
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
2019-09-20Update time zone data files to tzdata release 2019c.Tom Lane
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.
2019-09-20Fix some minor spec-compliance issues in jsonpath lexer.Tom Lane
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
2019-09-20Revert "Add DECLARE STATEMENT support to ECPG."Tom Lane
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
2019-09-20Fix progress report of REINDEX INDEXAlvaro Herrera
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
2019-09-20Provide stable test for NULL-values in KNN SP-GiSTAlexander Korotkov
f5f084fc3e has removed test because of its instability. This commit provides alternative test with determined ordering using extra ORDER BY expression. Backpatch-through: 12
2019-09-20Fix typo in commit 82fa3ff8672.Amit Kapila
Reported-By: Kuntal Ghosh (off-list) Backpatch-through: 9.4, like 82fa3ff8672
2019-09-20Remove unstable KNN SP-GiST testAlexander Korotkov
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
2019-09-20Fix freeing old values in index_store_float8_orderby_distances()Alexander Korotkov
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
2019-09-19Improve handling of NULLs in KNN-GiST and KNN-SP-GiSTAlexander Korotkov
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
2019-09-19Doc: improve documentation around jsonpath regular expressions.Tom Lane
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
2019-09-19GSSAPI error message improvementsPeter Eisentraut
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.
2019-09-19doc: Improve a release notes itemPeter Eisentraut
2019-09-19Fix typo in commit 578b229718.Amit Kapila
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
2019-09-19doc: Some release notes tweakingPeter Eisentraut
Improve the LDAP DNS SRV item.
2019-09-19Revert change of ecpglib major versionPeter Eisentraut
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
2019-09-19Doc: Fix incorrect mention to connection_object in CONNECT command of ECPGMichael Paquier
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
2019-09-19Doc: document autovacuum interruption.Amit Kapila
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
2019-09-18pg_upgrade/test.sh: Quote sed(1) argumentAlvaro Herrera
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
2019-09-18Doc: Update FDW documentation about direct foreign table modification.Etsuro Fujita
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
2019-09-17Fix bogus handling of XQuery regex option flags.Tom Lane
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
generated by cgit v1.2.3 (git 2.46.0) at 2025-10-22 21:43:10 +0000