aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
...
* Remove another test that doesn't work on Windows.Heikki Linnakangas2020-11-13
| | | | | | Apparently double-quotes are not allowed in filenames on Windows, either. Per buildfarm.
* doc: clarify where to find pg_type_d.h (PG 11+) and pg_type.hBruce Momjian2020-11-12
| | | | | | | | | | These files are in compiled directories and install directories. Reported-by: e.indrupskaya@postgrespro.ru Discussion: https://postgr.es/m/160379609706.24746.7506163279454026608@wrigleys.postgresql.org Backpatch-through: 9.5
* docs: mention that expression indexes need analyzeBruce Momjian2020-11-12
| | | | | | | | | | | | | 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
* change wire protocol data type for history file contentBruce Momjian2020-11-12
| | | | | | | | | | | | | This was marked as BYTEA, but is more like TEXT, which is how we already pass the history timeline file name. Internally, we don't do any encoding or bytea escape handling, but TEXT seems closest. This should cause no behavioral change. Reported-by: Brar Piening Discussion: https://postgr.es/m/6a1b9cd9-17e3-df67-be55-86102af6bdf5@gmx.de Backpatch-through: master
* Remove tests that don't work on Windows.Heikki Linnakangas2020-11-12
| | | | | | | | | | On Windows, a filename cannot contain backslashes, because a backslash is used directory separator. Remove tests I added in commit 9c4f5192f that tried to do that. We could perhaps use a SKIP block to only skip them on Windows, but I'm not sure how exactly to formulate that, so just remove the tests to make the buildfarm green again. Per buildfarm.
* pg_trgm: fix crash in 2-item picksplitAndrew Gierth2020-11-12
| | | | | | | | | | | | | | | | | | | | 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://postgr.es/m/87k0usfdxg.fsf@news-spur.riddles.org.uk
* Allow pg_rewind to use a standby server as the source system.Heikki Linnakangas2020-11-12
| | | | | | | | | | | | | | Using a hot standby server as the source has not been possible, because pg_rewind creates a temporary table in the source system, to hold the list of file ranges that need to be fetched. Refactor it to queue up the file fetch requests in pg_rewind's memory, so that the temporary table is no longer needed. Also update the logic to compute 'minRecoveryPoint' correctly, when the source is a standby server. Reviewed-by: Kyotaro Horiguchi, Soumyadeep Chakraborty Discussion: https://www.postgresql.org/message-id/0c5b3783-af52-3ee5-f8fa-6e794061f70d%40iki.fi
* Clean up optional rules in grammarPeter Eisentraut2020-11-12
| | | | | | | | | Various rules for optional keywords contained unnecessary rules and type declarations. Remove those, thus making the output a tiny bit smaller. Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Discussion: https://www.postgresql.org/message-id/flat/e9eed669-e32d-6919-fed4-acc0daea857b%40enterprisedb.com
* Fix typo in contrib/pg_trgm/pg_trgm--1.4--1.5.sqlAlexander Korotkov2020-11-12
| | | | Backpatch-through: 13
* Use standard SIGHUP and SIGTERM handlers in walreceiver.Fujii Masao2020-11-12
| | | | | | | | | | | | | | | | | Commit 1e53fe0e70 changed background processes so that they use standard SIGHUP handler. Like that, this commit makes walreceiver use standard SIGHUP and SIGTERM handlers, to simplify the code. As the side effect of this commit, walreceiver can wake up and process the configuration files promptly when receiving SIGHUP. Because the standard SIGHUP handler sets the latch. On the other hand, previously there could be a time lag between the receipt of SIGHUP and the process of configuration files since the dedicated handler didn't set the latch. Author: Bharath Rupireddy, tweaked by Fujii Masao Reviewed-by: Kyotaro Horiguchi, Fujii Masao Discussion: https://postgr.es/m/CALj2ACXPorUqePswDtOeM_s82v9RW32E1fYmOPZ5NuE+TWKj_A@mail.gmail.com
* Fix name of the macro for getting signature length trgm_gist.cAlexander Korotkov2020-11-12
| | | | | | | | | 911e702077 has introduced the opclass parameters including signature length for a set of GiST opclasses. Due to copy-pasting, macro for getting the signature length in trgm_gist.c was named LTREE_GET_ASIGLEN(). Fix that by renaming this macro to just GET_SIGLEN(). Backpatch-through: 13
* pg_stat_statements: track number of rows processed by REFRESH MATERIALIZED VIEW.Fujii Masao2020-11-12
| | | | | | | | | | | | | | | | | | | | Commit 6023b7ea71 allowed pg_stat_statements to track the number of rows retrieved or affected by some utility commands including CREATE MATERIALIZED VIEW. However it did not track the rowcount of REFRESH MATERIALIZED VIEW. This commit allows pg_stat_statements to track that. To track that, this commit changes the query completion for REFRESH MATERIALIZED VIEW so that it saves the rowcount. But note that the rowcount is still not displayed in the command completion tag output. That is, the display_rowcount flag of CMDTAG_REFRESH_MATERIALIZED_VIEW command tag is left false in cmdtaglist.h. Otherwise, the change of completion tag output might break applications using it. Author: Katsuragi Yuta, Seino Yuki Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/71f6bc72f8bbaa06e701f8bd2562c347@oss.nttdata.com Discussion: https://postgr.es/m/aadbfba9-e4bb-9531-6b3a-d13c31c8f4fe@oss.nttdata.com
* Remove useless SHA256 initialization when not using backup manifestsMichael Paquier2020-11-12
| | | | | | | | | | | | | | | | | | | | Attempting to take a base backup with Postgres linking to a build of OpenSSL with FIPS enabled currently fails with or even without a backup manifest requested because of this mandatory SHA256 initialization used for the manifest file itself. However, there is no need to do this initialization at all if backup manifests are not needed because there is no data to append to the manifest. Note that being able to use backup manifests with OpenSSL+FIPS requires a switch of the SHA2 implementation to use EVP, which would cause an ABI breakage so this cannot be backpatched to 13 as it has been already released, but at least avoiding this SHA256 initialization gives users the possibility to take a base backup even when specifying --no-manifest with pg_basebackup. Author: Michael Paquier Discussion: https://postgr.es/m/20201110020014.GE1887@paquier.xyz Backpatch-through: 13
* Remove duplicate code in brin_memtuple_initializeTomas Vondra2020-11-11
| | | | | | | | | | 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 some stray whitespace in parser filesPeter Eisentraut2020-11-11
|
* Remove line missed in previous commitMagnus Hagander2020-11-11
|
* Remove vacuumdb --analyze-in-stages from pg_upgrade testsMagnus Hagander2020-11-11
| | | | | | | | This step was only there to test the script when we generated those, but commit 8f113698b6 removed those scripts, so it's not needed anymore. Reported-By: Peter Eisentraut Discussion: https://postgr.es/m/ea403f46-2b33-a7de-618e-9cab35a698c8@enterprisedb.com
* Add pg_nodiscard decorations to some functionsPeter Eisentraut2020-11-11
| | | | | | | | Especially for the list API such as lappend() forgetting to assign the return value is a common problem. Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/flat/e3753562-99cd-b65f-5aca-687dfd1ec2fc@2ndquadrant.com
* Add pg_nodiscard function declaration specifierPeter Eisentraut2020-11-11
| | | | | | | | | | pg_nodiscard means the compiler should warn if the result of a function call is ignored. The name "nodiscard" is chosen in alignment with (possibly future) C and C++ standards. It maps to the GCC attribute warn_unused_result. Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/flat/e3753562-99cd-b65f-5aca-687dfd1ec2fc@2ndquadrant.com
* Fix cases of discarding result from list API functionsPeter Eisentraut2020-11-11
| | | | | | | | | | | | Two cases violated list APIs by throwing away the return value. While the code was technically correct, it relied on internal knowledge of the list implementation, and the code wasn't really gaining anything that way. It is planned to make this a compiler warning in the future, so just fix these cases by assigning the return value properly. Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://www.postgresql.org/message-id/flat/e3753562-99cd-b65f-5aca-687dfd1ec2fc@2ndquadrant.com
* Fix and simplify some usages of TimestampDifference().Tom Lane2020-11-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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://postgr.es/m/3b1c053a21c07c1ed5e00be3b2b855ef@postgrespro.ru
* doc: fix spelling "connction" to "connection"Bruce Momjian2020-11-10
| | | | | | | | | | 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.Tom Lane2020-11-10
| | | | | | | | | | | | | 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://postgr.es/m/1401824.1604537031@sss.pgh.pa.us Discussion: https://postgr.es/m/E1kaQ2c-0005lx-Eg@gemulon.postgresql.org
* pg_rewind: Fix thinko in parsing target WAL.Heikki Linnakangas2020-11-10
| | | | | | | | | | | It's entirely possible to see WAL for a relation that doesn't exist in the target anymore. That happens when the relation was dropped later. The refactoring in commit eb00f1d4b broke that case, by sanity-checking the file type in the target before checking the flag forwhether it exists there at all. I noticed this during manual testing. Modify the 001_basic.pl test so that it covers this case.
* Fix out of date commentMagnus Hagander2020-11-10
|
* Remove -o option to postmasterMagnus Hagander2020-11-10
| | | | | | | This option was declared obsolete many years ago. Reviewed-By: Tom Lane Discussion: https://postgr.es/m/CABUevEyOE=9CQwZm2j=vwP5+6OLCSoxn9pBjK8gyRdkTzMfqtQ@mail.gmail.com
* jit: Add support for LLVM 12.Andres Freund2020-11-09
| | | | | | | | | | | | | | | | | | LLVM 12, to be released in a few months, made some breaking changes to the Orc JIT interface. OrcV2 eventually will make it easier to support features like concurrent JIT compilation, but this commit only allows to compile against LLVM 12. This commit is a bit bigger than desirable. That partially is because the V2 interface is more granular than V1 interface, but also because I chose to make some minor changes to < LLVM 12 code to keep the code somewhat readable. The LLVM 12 support will need to be backpatched. I plan to do so after the patch stewed on the buildfarm for a few days. Author: Andres Freund Discussion: https://postgr.es/m/20201016011244.pmyvr3ee2gbzplq4@alap3.anarazel.de
* Doc: clarify data type behavior of COALESCE and NULLIF.Tom Lane2020-11-09
| | | | | | | After studying the code, NULLIF is a lot more subtle than you might have guessed. Discussion: https://postgr.es/m/160486028730.25500.15740897403028593550@wrigleys.postgresql.org
* Remove ineffective heapam CHECK_FOR_INTERRUPTS().Peter Geoghegan2020-11-09
| | | | | | | | | | | | Remove a CHECK_FOR_INTERRUPTS() call that could never actually handle an interrupt. We always have a heap page buffer lock at this point. Having a useless CHECK_FOR_INTERRUPTS() call is harmless but misleading. It is probably possible to work around the immediate problem by moving the CHECK_FOR_INTERRUPTS() to before the heap page buffer lock is acquired. That isn't enough to make the function responsive to interrupts, though. The index AM caller will still hold an exclusive buffer lock of its own.
* Ignore attempts to \gset into specially treated variables.Noah Misch2020-11-09
| | | | | | | | | | | | | | | If an interactive psql session used \gset when querying a compromised server, the attacker could execute arbitrary code as the operating system account running psql. Using a prefix not found among specially treated variables, e.g. every lowercase string, precluded the attack. Fix by issuing a warning and setting no variable for the column in question. Users wanting the old behavior can use a prefix and then a meta-command like "\set HISTSIZE :prefix_HISTSIZE". Back-patch to 9.5 (all supported versions). Reviewed by Robert Haas. Reported by Nick Cleaton. Security: CVE-2020-25696
* In security-restricted operations, block enqueue of at-commit user code.Noah Misch2020-11-09
| | | | | | | | | | | | | | | | | | Specifically, this blocks DECLARE ... WITH HOLD and firing of deferred triggers within index expressions and materialized view queries. An attacker having permission to create non-temp objects in at least one schema could execute arbitrary SQL functions under the identity of the bootstrap superuser. One can work around the vulnerability by disabling autovacuum and not manually running ANALYZE, CLUSTER, REINDEX, CREATE INDEX, VACUUM FULL, or REFRESH MATERIALIZED VIEW. (Don't restore from pg_dump, since it runs some of those commands.) Plain VACUUM (without FULL) is safe, and all commands are fine when a trusted user owns the target object. Performance may degrade quickly under this workaround, however. Back-patch to 9.5 (all supported versions). Reviewed by Robert Haas. Reported by Etienne Stalmans. Security: CVE-2020-25695
* Remove analyze_new_cluster script from pg_upgradeMagnus Hagander2020-11-09
| | | | | | | | | Since this script just runs vacuumdb anyway, remove the script and replace the instructions to run it with instructions to run vacuumdb directly. Reviewed-By: Michael Paquier Discussion: https://postgr.es/m/CABUevEwg5LDFzthhxzSj7sZGMiVsZe0VVNbzzwTQOHJ=rN7+5A@mail.gmail.com
* Remove incorrect %s in stringMagnus Hagander2020-11-09
| | | | | | | | | Appears to have been a copy/paste error in the original commit that moved the messages to fe_utils/. Author: Tang, Haiying <tanghy.fnst@cn.fujitsu.com> Backpatch-through: 13 Discussion: https://postgr.es/m/3321cbcea76d4d2c8320a05c19b9304a@G08CNEXMBPEKD05.g08.fujitsu.local
* doc: Add note about pg_settings and customized options into catalogs.sgml.Fujii Masao2020-11-09
| | | | | | | | | | The pg_settings view does not display customized options until the extension module that defines them has been loaded. This commit add the note about that behavior, into the docs. Author: John Naylor Reviewed-by: Tom Lane, Fujii Masao Discussion: https://postgr.es/m/CAFBsxsGsBZsG=cLM0Op5HFb2Ks6SzJrOc_eRO_jcKSNuqFRKnQ@mail.gmail.com
* Fix parsePGArray() error checking in pg_dump.Thomas Munro2020-11-09
| | | | | | | | | | | | | | | Coverity complained about a defect in commit 257836a7: Calling "parsePGArray" without checking return value (as is done elsewhere 11 out of 13 times). Fix, and also check for empty strings explicitly (NULL as represented by PQgetvalue()). That worked correctly before only because parsePGArray() happens to set *nitems = 0 when it fails on an empty string. Also convert a sanity check assertion to an error to be more paranoid, and pgindent a nearby line. Reported-by: Michael Paquier <michael@paquier.xyz>
* In INSERT/UPDATE, use the table's real tuple descriptor as target.Tom Lane2020-11-08
| | | | | | | | | | | | | | | | | | | | | | | This back-patches commit 20d3fe900 into the v12 and v13 branches. At the time I thought that commit was not fixing any observable bug, but Bertrand Drouvot showed otherwise: adding a dropped column to the previously-considered scenario crashes v12 and v13, unless the dropped column happens to be an integer. That is, of course, because the tupdesc we derive from the plan output tlist fails to describe the dropped column accurately, so that we'll do the wrong thing with a tuple in which that column isn't NULL. There is no bug in pre-v12 branches because they already did use the table's real tuple descriptor for any trigger-returned tuple. It seems that this set of bugs can be blamed on the changes that removed es_trig_tuple_slot, though I've not attempted to pin that down precisely. Although there's no code change needed in HEAD, update the test case to include a dropped column there too. Discussion: https://postgr.es/m/db5d97c8-f48a-51e2-7b08-b73d5434d425@amazon.com Discussion: https://postgr.es/m/16644-5da7ef98a7ac4545@postgresql.org
* Fix assertion in collation version lookup.Thomas Munro2020-11-08
| | | | | | | Commit 257836a7 included an assertion that a version lookup routine is not trying to look up "C" or "POSIX", but that case is reachable with the user-facing SQL function pg_collation_actual_version(). Remove the assertion.
* Fix test for error message changePeter Eisentraut2020-11-08
| | | | fix for 6be725e701611660b36642de9ff1d665a1eb24f5
* Improve nbtree README's LP_DEAD section.Peter Geoghegan2020-11-07
| | | | | | | | | | The description of how LP_DEAD bit setting by index scans works following commit 2ed5b87f was rather unclear. Clean that up a bit. Also refer to LP_DEAD bit setting within _bt_check_unique() at the start of the same section. This mechanism may actually be more important than the generic kill_prior_tuple mechanism that the section focuses on, so it at least deserves to be mentioned in passing.
* Message style improvementsAlvaro Herrera2020-11-07
| | | | | | | | | | | | | * Avoid pointlessly highlighting that an index vacuum was executed by a parallel worker; user doesn't care. * Don't give the impression that a non-concurrent reindex of an invalid index on a TOAST table would work, because it wouldn't. * Add a "translator:" comment for a mysterious message. Discussion: https://postgr.es/m/20201107034943.GA16596@alvherre.pgsql Reviewed-by: Michael Paquier <michael@paquier.xyz>
* Fix redundant error messages in client toolsPeter Eisentraut2020-11-07
| | | | | | A few client tools duplicate error messages already provided by libpq. Discussion: https://www.postgresql.org/message-id/flat/3e937641-88a1-e697-612e-99bba4b8e5e4%40enterprisedb.com
* Avoid re-using output variables in new ecpg test case.Tom Lane2020-11-07
| | | | | | | | | The buildfarm thinks this leads to memory stomps, though annoyingly I can't duplicate that here. The existing code in strings.pgc is doing something that doesn't seem to be sanctioned at all really by the documentation, but I'm disinclined to try to make that nicer right now. Let's just declare some more output variables in hopes of working around it.
* Fix ecpg's mishandling of B'...' and X'...' literals.Tom Lane2020-11-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These were broken in multiple ways: * The xbstart and xhstart lexer actions neglected to set "state_before_str_start" before transitioning to the xb/xh states, thus possibly resulting in "internal error: unreachable state" later. * The test for valid string contents at the end of xb state was flat out wrong, as it accounted incorrectly for the "b" prefix that the xbstart action had injected. Meanwhile, the xh state had no such check at all. * The generated literal value failed to include any quote marks. * The grammar did the wrong thing anyway, typically ignoring the literal value and emitting something else, since BCONST and XCONST tokens were handled randomly differently from SCONST tokens. The first of these problems is evidently an oversight in commit 7f380c59f, but the others seem to be very ancient. The lack of complaints shows that ECPG users aren't using these syntaxes much (although I do vaguely remember one previous complaint). As written, this patch is dependent on 7f380c59f, so it can't go back further than v13. Given the shortage of complaints, I'm not excited about adapting the patch to prior branches. Report and patch by Shenhao Wang (test case adjusted by me) Discussion: https://postgr.es/m/d6402f1bacb74ecba22ef715dbba17fd@G08CNEXMBPEKD06.g08.fujitsu.local
* Move catalog index declarationsPeter Eisentraut2020-11-07
| | | | | | | | | | | | Move the system catalog index declarations from catalog/indexing.h to the respective parent tables' catalog/pg_*.h files. The original reason for having it split was that the old genbki system produced the output in the order of the catalog files it read, so all the indexing stuff needed to come separately. But this is no longer the case, and keeping it together makes more sense. Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://www.postgresql.org/message-id/flat/c7cc82d6-f976-75d6-2e3e-b03d2cab26bb@2ndquadrant.com
* Move catalog toast table declarationsPeter Eisentraut2020-11-07
| | | | | | | | | | | | Move the system catalog toast table declarations from catalog/toasting.h to the respective parent tables' catalog/pg_*.h files. The original reason for having it split was that the old genbki system produced the output in the order of the catalog files it read, so all the toasting stuff needed to come separately. But this is no longer the case, and keeping it together makes more sense. Reviewed-by: John Naylor <john.naylor@enterprisedb.com> Discussion: https://www.postgresql.org/message-id/flat/c7cc82d6-f976-75d6-2e3e-b03d2cab26bb@2ndquadrant.com
* Plug memory leak in index_get_partitionAlvaro Herrera2020-11-06
| | | | | | | | | | | | | | | The list of indexes was being leaked when asked for an index that doesn't have an index partition in the table partition. Not a common case admittedly --and in most cases where it occurs, caller throws an error anyway-- but worth fixing for cleanliness and in case any third-party code is calling this function. While at it, remove use of lfirst_oid() to obtain a value we already have. Author: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/20201105203606.GF22691@telsasoft.com
* Add GUC_LIST_INPUT and GUC_LIST_QUOTE to unix_socket_directoriesMichael Paquier2020-11-07
| | | | | | | | | | | | | | | | | | This should have been done in the initial commit that made unix_socket_directories a list as of c9b0cbe. This change allows to support correctly the case of ALTER SYSTEM, where it is possible to specify multiple paths as a list, like the following pattern where flattening is applied to each item: ALTER SYSTEM SET unix_socket_directories = '/path1', '/path2'; Any parameters specified in postgresql.conf are parsed the same way, so there is no compatibility change. pg_dump has a hardcoded list of parameters marked with GUC_LIST_QUOTE, that gets its routine update. These are reordered alphabetically for clarity. Author: Ian Lawrence Barwick Reviewed-by: Peter Eisentraunt, Tom Lane, Michael Paquier Discussion: https://postgr.es/m/CAB8KJ=iMOtNY6_sUwV=LQVCJ2zgYHBDyNzVfvE5GN3WQ3v9kQg@mail.gmail.com
* Fix minor issues with new unicode {de,re}composition codeMichael Paquier2020-11-07
| | | | | | | | | | | | The table generation script would incorrectly complain in the recomposition sorting when matching code points. This would not have caused the generation of an incorrect table. Note that this condition is not reachable yet, but could have been reached with future updates. pg_bswap.h does not need to be included in the frontend.x Author: John Naylor Discussion: https://postgr.es/m/CAFBsxsGWmExpvv=61vtDKCs7+kBbhkwBDL2Ph9CacziFKnV_yw@mail.gmail.com
* Properly detoast data in brin_form_tupleTomas Vondra2020-11-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | brin_form_tuple failed to consider the values may be toasted, inserting the toast pointer into the index. This may easily result in index corruption, as the toast data may be deleted and cleaned up by vacuum. The cleanup however does not care about indexes, leaving invalid toast pointers behind, which triggers errors like this: ERROR: missing chunk number 0 for toast value 16433 in pg_toast_16426 A less severe consequence are inconsistent failures due to the index row being too large, depending on whether brin_form_tuple operated on plain or toasted version of the row. For example CREATE TABLE t (val TEXT); INSERT INTO t VALUES ('... long value ...') CREATE INDEX idx ON t USING brin (val); would likely succeed, as the row would likely include toast pointer. Switching the order of INSERT and CREATE INDEX would likely fail: ERROR: index row size 8712 exceeds maximum 8152 for index "idx" because this happens before the row values are toasted. The bug exists since PostgreSQL 9.5 where BRIN indexes were introduced. So backpatch all the way back. Author: Tomas Vondra Reviewed-by: Alvaro Herrera Backpatch-through: 9.5 Discussion: https://postgr.es/m/20201001184133.oq5uq75sb45pu3aw@development Discussion: https://postgr.es/m/20201104010544.zexj52mlldagzowv%40development
* Revert "Accept relations of any kind in LOCK TABLE".Tom Lane2020-11-06
| | | | | | | | | | Revert 59ab4ac32, as well as the followup fix 33862cb9c, in all branches. We need to think a bit harder about what the behavior of LOCK TABLE on views should be, and there's no time for that before next week's releases. We'll take another crack at this later. Discussion: https://postgr.es/m/16703-e348f58aab3cf6cc@postgresql.org
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-04 03:41:58 +0000