aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
...
* Release notes for 13.4, 12.8, 11.13, 10.18, 9.6.23.Tom Lane2021-08-08
|
* Really fix the ambiguity in REFRESH MATERIALIZED VIEW CONCURRENTLY.Tom Lane2021-08-07
| | | | | | | | | | | | | | | | | | Rather than trying to pick table aliases that won't conflict with any possible user-defined matview column name, adjust the queries' syntax so that the aliases are only used in places where they can't be mistaken for column names. Mostly this consists of writing "alias.*" not just "alias", which adds clarity for humans as well as machines. We do have the issue that "SELECT alias.*" acts differently from "SELECT alias", but we can use the same hack ruleutils.c uses for whole-row variables in SELECT lists: write "alias.*::compositetype". We might as well revert to the original aliases after doing this; they're a bit easier to read. Like 75d66d10e, back-patch to all supported branches. Discussion: https://postgr.es/m/2488325.1628261320@sss.pgh.pa.us
* Adjust the integer overflow tests in the numeric code.Dean Rasheed2021-08-06
| | | | | | | | | | | | | | | | | | | | Formerly, the numeric code tested whether an integer value of a larger type would fit in a smaller type by casting it to the smaller type and then testing if the reverse conversion produced the original value. That's perfectly fine, except that it caused a test failure on buildfarm animal castoroides, most likely due to a compiler bug. Instead, do these tests by comparing against PG_INT16/32_MIN/MAX. That matches existing code in other places, such as int84(), which is more widely tested, and so is less likely to go wrong. While at it, add regression tests covering the numeric-to-int8/4/2 conversions, and adjust the recently added tests to the style of 434ddfb79a (on the v11 branch) to make failures easier to diagnose. Per buildfarm via Tom Lane, reviewed by Tom Lane. Discussion: https://postgr.es/m/2394813.1628179479%40sss.pgh.pa.us
* Fix wordingPeter Eisentraut2021-08-06
|
* First-draft release notes for 13.4.Tom Lane2021-08-06
| | | | | As usual, the release notes for older branches will be made by cutting these down, but put them up for community review first.
* postgres_fdw: Fix issues with generated columns in foreign tables.Etsuro Fujita2021-08-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | postgres_fdw imported generated columns from the remote tables as plain columns, and caused failures like "ERROR: cannot insert a non-DEFAULT value into column "foo"" when inserting into the foreign tables, as it tried to insert values into the generated columns. To fix, we do the following under the assumption that generated columns in a postgres_fdw foreign table are defined so that they represent generated columns in the underlying remote table: * Send DEFAULT for the generated columns to the foreign server on insert or update, not generated column values computed on the local server. * Add to postgresImportForeignSchema() an option "import_generated" to include column generated expressions in the definitions of foreign tables imported from a foreign server. The option is true by default. The assumption seems reasonable, because that would make a query of the postgres_fdw foreign table return values for the generated columns that are consistent with the generated expression. While here, fix another issue in postgresImportForeignSchema(): it tried to include column generated expressions as column default expressions in the foreign table definitions when the import_default option was enabled. Per bug #16631 from Daniel Cherniy. Back-patch to v12 where generated columns were added. Discussion: https://postgr.es/m/16631-e929fe9db0ffc7cf%40postgresql.org
* Fix division-by-zero error in to_char() with 'EEEE' format.Dean Rasheed2021-08-05
| | | | | | | | | | | | | | | | | | | | This fixes a long-standing bug when using to_char() to format a numeric value in scientific notation -- if the value's exponent is less than -NUMERIC_MAX_DISPLAY_SCALE-1 (-1001), it produced a division-by-zero error. The reason for this error was that get_str_from_var_sci() divides its input by 10^exp, which it produced using power_var_int(). However, the underflow test in power_var_int() causes it to return zero if the result scale is too small. That's not a problem for power_var_int()'s only other caller, power_var(), since that limits the rscale to 1000, but in get_str_from_var_sci() the exponent can be much smaller, requiring a much larger rscale. Fix by introducing a new function to compute 10^exp directly, with no rscale limit. This also allows 10^exp to be computed more efficiently, without any numeric multiplication, division or rounding. Discussion: https://postgr.es/m/CAEZATCWhojfH4whaqgUKBe8D5jNHB8ytzemL-PnRx+KCTyMXmg@mail.gmail.com
* C comment: correct heading of extension queryBruce Momjian2021-08-03
| | | | | | | | Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20210803161345.GZ12533@telsasoft.com Backpatch-through: 9.6
* doc: interval spill method for units greater than monthsBruce Momjian2021-08-03
| | | | | | | | | | | Units are _truncated_ to months, but only in back branches since the recent commit. Reported-by: Bryn Llewellyn Discussion: https://postgr.es/m/BDAE4B56-3337-45A2-AC8A-30593849D6C0@yugabyte.com Backpatch-through: 9.6 to 14
* pg_upgrade: warn about extensions that need updatingBruce Momjian2021-08-03
| | | | | | | | | | Also create a script that can be run to update them. Reported-by: Dave Cramer Discussion: https://postgr.es/m/CADK3HHKawwbOcGwMGnDuAf3-U8YfvTcS8jqDv3UM=niijs3MMA@mail.gmail.com Backpatch-through: 9.6
* pg_upgrade: improve docs about extension upgradesBruce Momjian2021-08-03
| | | | | | | | | | | The previous wording was unclear about the steps needed to upgrade extensions, and how to update them after pg_upgrade. Reported-by: Dave Cramer Discussion: https://postgr.es/m/CADK3HHKawwbOcGwMGnDuAf3-U8YfvTcS8jqDv3UM=niijs3MMA@mail.gmail.com Backpatch-through: 9.6
* doc: mention inheritance's tableoid can be used in partitioningBruce Momjian2021-08-03
| | | | | | | | | | | Previously tableoid was not mentioned in the partition doc section. We only had a link to the "all the normal rules" of inheritance section. Reported-by: michal.palenik@freemap.sk Discussion: https://postgr.es/m/162627031219.693.11508199541771263335@wrigleys.postgresql.org Backpatch-through: 10
* doc: add example of using pg_dump with GNU split and gzipBruce Momjian2021-08-03
| | | | | | | | | | This is only possible with GNU split, not other versions like BSD split. Reported-by: jim@jdoherty.net Discussion: https://postgr.es/m/162653459215.701.6323855956817776386@wrigleys.postgresql.org Backpatch-through: 9.6
* Use elog, not Assert, to report failure to provide an outer snapshot.Tom Lane2021-07-31
| | | | | | | | | | | | | | | | As of commit 84f5c2908, executing SQL commands (via SPI or otherwise) requires having either an active Portal, or a caller-established active snapshot. We were simply Assert'ing that that's the case. But we've now had a couple different reports of people testing extensions that didn't meet this requirement, and were confused by the resulting crash. Let's convert the Assert to a test-and-elog, in hopes of making the issue clearer for extension authors. Per gripes from Liu Huailing and RekGRpth. Back-patch to v11, like the prior commit. Discussion: https://postgr.es/m/OSZPR01MB6215671E3C5956A034A080DFBEEC9@OSZPR01MB6215.jpnprd01.prod.outlook.com Discussion: https://postgr.es/m/17035-14607d308ac8643c@postgresql.org
* Fix corner-case errors and loss of precision in numeric_power().Dean Rasheed2021-07-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a couple of related problems that arise when raising numbers to very large powers. Firstly, when raising a negative number to a very large integer power, the result should be well-defined, but the previous code would only cope if the exponent was small enough to go through power_var_int(). Otherwise it would throw an internal error, attempting to take the logarithm of a negative number. Fix this by adding suitable handling to the general case in power_var() to cope with negative bases, checking for integer powers there. Next, when raising a (positive or negative) number whose absolute value is slightly less than 1 to a very large power, the result should approach zero as the power is increased. However, in some cases, for sufficiently large powers, this would lose all precision and return 1 instead of 0. This was due to the way that the local_rscale was being calculated for the final full-precision calculation: local_rscale = rscale + (int) val - ln_dweight + 8 The first two terms on the right hand side are meant to give the number of significant digits required in the result ("val" being the estimated result weight). However, this failed to account for the fact that rscale is clipped to a maximum of NUMERIC_MAX_DISPLAY_SCALE (1000), and the result weight might be less then -1000, causing their sum to be negative, leading to a loss of precision. Fix this by forcing the number of significant digits calculated to be nonnegative. It's OK for it to be zero (when the result weight is less than -1000), since the local_rscale value then includes a few extra digits to ensure an accurate result. Finally, add additional underflow checks to exp_var() and power_var(), so that they consistently return zero for cases like this where the result is indistinguishable from zero. Some paths through this code already returned zero in such cases, but others were throwing overflow errors. Dean Rasheed, reviewed by Yugo Nagata. Discussion: http://postgr.es/m/CAEZATCW6Dvq7+3wN3tt5jLj-FyOcUgT5xNoOqce5=6Su0bCR0w@mail.gmail.com
* Fix range check in ECPG numeric to int conversionJohn Naylor2021-07-30
| | | | | | | | | | | The previous coding guarded against -INT_MAX instead of INT_MIN, leading to -2147483648 being rejected as out of range. Per bug #17128 from Kevin Sweet Discussion: https://www.postgresql.org/message-id/flat/17128-55a8a879727a3e3a%40postgresql.org Reviewed-by: Tom Lane Backpatch to all supported branches
* Close yet another race condition in replication slot test codeAlvaro Herrera2021-07-29
| | | | | | | | | | | | Buildfarm shows that this test has a further failure mode when a checkpoint starts earlier than expected, so we detect a "checkpoint completed" line that's not the one we want. Change the config to try and prevent this. Per buildfarm Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Discussion: https://postgr.es/m/20210729.162038.534808353849568395.horikyota.ntt@gmail.com
* Add missing exit() in pg_verifybackup when failing to find pg_waldumpMichael Paquier2021-07-29
| | | | | | | | | | | | pg_verifybackup needs by default pg_waldump to check after a range of WAL segments required for a backup, except if --no-parse-wal is specified. The code checked for the presence of the binary pg_waldump in an installation and reported an error, but it forgot to properly exit(). This could lead to confusing errors reported. Reviewed-by: Robert Haas, Fabien Coelho Discussion: https://postgr.es/m/YQDMdB+B68yePFeT@paquier.xyz Backpatch-through: 13
* Update minimum recovery point on truncation during WAL replay of abort record.Fujii Masao2021-07-29
| | | | | | | | | | | | | | | | If a file is truncated, we must update minRecoveryPoint. Once a file is truncated, there's no going back; it would not be safe to stop recovery at a point earlier than that anymore. Commit 7bffc9b7bf changed xact_redo_commit() so that it updates minRecoveryPoint on truncation, but forgot to change xact_redo_abort(). Back-patch to all supported versions. Reported-by: mengjuan.cmj@alibaba-inc.com Author: Fujii Masao Reviewed-by: Heikki Linnakangas Discussion: https://postgr.es/m/b029fce3-4fac-4265-968e-16f36ff4d075.mengjuan.cmj@alibaba-inc.com
* Doc: Clarify lock levels taken during ATTACH PARTITIONDavid Rowley2021-07-28
| | | | | | | | | | | | | | | | | It wasn't all that clear which lock levels, if any, would be held on the DEFAULT partition during an ATTACH PARTITION operation. Also, clarify which locks will be taken if the DEFAULT partition or the table being attached are themselves partitioned tables. Here I'm only backpatching to v12 as before then we obtained an ACCESS EXCLUSIVE lock on the partitioned table. It seems much less relevant to mention which locks are taken on other tables when the partitioned table itself is locked with an ACCESS EXCLUSIVE lock. Author: Matthias van de Meent, David Rowley Discussion: https://postgr.es/m/CAEze2WiTB6iwrV8W_J=fnrnZ7fowW3qu-8iQ8zCHP3FiQ6+o-A@mail.gmail.com Backpatch-through: 12
* Set pg_setting.pending_restart when pertinent config lines are removedAlvaro Herrera2021-07-27
| | | | | | | | | | | | | | | | | This changes the behavior of examining the pg_file_settings view after changing a config option that requires restart. The user needs to know that any change of such options does not take effect until a restart, and this worked correctly if the line is edited without removing it. However, for the case where the line is removed altogether, the flag doesn't get set, because a flag was only set in set_config_option, but that's not called for lines removed. Repair. (Ref.: commits 62d16c7fc561 and a486e35706ea) Author: Álvaro Herrera <alvherre@alvh.no-ip.org> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us> Discussion: https://postgr.es/m/202107262302.xsfdfc5sb7sh@alvherre.pgsql
* Avoid using ambiguous word "non-negative" in error messages.Fujii Masao2021-07-28
| | | | | | | | | | | | | | | | | | | | | | The error messages using the word "non-negative" are confusing because it's ambiguous about whether it accepts zero or not. This commit improves those error messages by replacing it with less ambiguous word like "greater than zero" or "greater than or equal to zero". Also this commit added the note about the word "non-negative" to the error message style guide, to help writing the new error messages. When postgres_fdw option fetch_size was set to zero, previously the error message "fetch_size requires a non-negative integer value" was reported. This error message was outright buggy. Therefore back-patch to all supported versions where such buggy error message could be thrown. Reported-by: Hou Zhijie Author: Bharath Rupireddy Reviewed-by: Kyotaro Horiguchi, Fujii Masao Discussion: https://postgr.es/m/OS0PR01MB5716415335A06B489F1B3A8194569@OS0PR01MB5716.jpnprd01.prod.outlook.com
* doc: for various substring funcs, document if only first matchBruce Momjian2021-07-26
| | | | | | | | Reported-by: troy@frericks.us Discussion: https://postgr.es/m/162614304115.701.2392941350859387646@wrigleys.postgresql.org Backpatch-through: 13
* pg_resetxlog: add option to set oldest xid & use by pg_upgradeBruce Momjian2021-07-26
| | | | | | | | | | | | | | | | | | Add pg_resetxlog -u option to set the oldest xid in pg_control. Previously -x set this value be -2 billion less than the -x value. However, this causes the server to immediately scan all relation's relfrozenxid so it can advance pg_control's oldest xid to be inside the autovacuum_freeze_max_age range, which is inefficient and might disrupt diagnostic recovery. pg_upgrade will use this option to better create the new cluster to match the old cluster. Reported-by: Jason Harvey, Floris Van Nee Discussion: https://postgr.es/m/20190615183759.GB239428@rfd.leadboat.com, 87da83168c644fd9aae38f546cc70295@opammb0562.comp.optiver.com Author: Bertrand Drouvot Backpatch-through: 9.6
* Harden pg_stat_statements tests against CLOBBER_CACHE_ALWAYS.Tom Lane2021-07-25
| | | | | | | | Turns out the buildfarm hasn't been testing this, which will soon change. Julien Rouhaud, per report from me Discussion: https://postgr.es/m/42557.1627229005@sss.pgh.pa.us
* Fix a couple of memory leaks in src/bin/pg_basebackup/Michael Paquier2021-07-26
| | | | | | | | | | These have been introduced by 7fbe0c8, and could happen for pg_basebackup and pg_receivewal. Per report from Coverity for the ones in walmethods.c, I have spotted the ones in receivelog.c after more review. Backpatch-through: 10
* Get rid of artificial restriction on hash table sizes on Windows.Tom Lane2021-07-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The point of introducing the hash_mem_multiplier GUC was to let users reproduce the old behavior of hash aggregation, i.e. that it could use more than work_mem at need. However, the implementation failed to get the job done on Win64, where work_mem is clamped to 2GB to protect various places that calculate memory sizes using "long int". As written, the same clamp was applied to hash_mem. This resulted in severe performance regressions for queries requiring a bit more than 2GB for hash aggregation, as they now spill to disk and there's no way to stop that. Getting rid of the work_mem restriction seems like a good idea, but it's a big job and could not conceivably be back-patched. However, there's only a fairly small number of places that are concerned with the hash_mem value, and it turns out to be possible to remove the restriction there without too much code churn or any ABI breaks. So, let's do that for now to fix the regression, and leave the larger task for another day. This patch does introduce a bit more infrastructure that should help with the larger task, namely pg_bitutils.h support for working with size_t values. Per gripe from Laurent Hasson. Back-patch to v13 where the behavior change came in. Discussion: https://postgr.es/m/997817.1627074924@sss.pgh.pa.us Discussion: https://postgr.es/m/MN2PR15MB25601E80A9B6D1BA6F592B1985E39@MN2PR15MB2560.namprd15.prod.outlook.com
* Make the standby server promptly handle interrupt signals.Fujii Masao2021-07-25
| | | | | | | | | | | | | | | | | | | This commit changes the startup process in the standby server so that it handles the interrupt signals after waiting for wal_retrieve_retry_interval on the latch and resetting it, before entering another wait on the latch. This change causes the standby server to promptly handle interrupt signals. Otherwise, previously, there was the case where the standby needs to wait extra five seconds to shutdown when the shutdown request arrived while the startup process was waiting for wal_retrieve_retry_interval on the latch. Author: Fujii Masao, but implementation idea is from Soumyadeep Chakraborty Reviewed-by: Soumyadeep Chakraborty Discussion: https://postgr.es/m/9d7e6ab0-8a53-ddb9-63cd-289bcb25fe0e@oss.nttdata.com Per discussion of BUG #17073, back-patch to all supported versions. Discussion: https://postgr.es/m/17073-1a5fdaed0fa5d4d0@postgresql.org
* Fix check for conflicting session- vs transaction-level locks.Tom Lane2021-07-24
| | | | | | | | | | | | | | | | | | | | | | | We have an implementation restriction that PREPARE TRANSACTION can't handle cases where both session-lifespan and transaction-lifespan locks are held on the same lockable object. (That's because we'd otherwise need to acquire a new PROCLOCK entry during post-prepare cleanup, which is an operation that might fail. The situation can only arise with odd usages of advisory locks, so removing the restriction is probably not worth the amount of effort it would take.) AtPrepare_Locks attempted to enforce this, but its logic was many bricks shy of a load, because it only detected cases where the session and transaction locks had the same lockmode. Locks of different modes on the same object would lead to the rather unhelpful message "PANIC: we seem to have dropped a bit somewhere". To fix, build a transient hashtable with one entry per locktag, not one per locktag + mode, and use that to detect conflicts. Per bug #17122 from Alexander Pyhalov. This bug is ancient, so back-patch to all supported branches. Discussion: https://postgr.es/m/17122-04f3c32098a62233@postgresql.org
* Make printf("%s", NULL) print "(null)" instead of crashing.Tom Lane2021-07-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We previously took a hard-line attitude that callers should never print a null string pointer, and doing so is worthy of an assertion failure or crash. However, we've long since flushed out any easy-to-find bugs of that nature. What remains is a lot of code that perhaps could fail that way in hard-to-reach corner cases. For example, in something as simple as ereport(ERROR, (errcode(ERRCODE_UNDEFINED_OBJECT), errmsg("constraint \"%s\" for table \"%s\" does not exist", conname, get_rel_name(relid)))); one must wonder whether it's completely guaranteed that get_rel_name cannot return NULL in this context. If such a situation did occur, the existing policy converts what might be a pretty minor bug into a server crash condition. This is not good for robustness. Hence, let's follow the lead of glibc and print "(null)" instead of failing. We should, of course, still consider it a bug if that behavior is reachable in ordinary use; but crashing seems less desirable than not crashing. This fix works across-the-board in v12 and up, where we always use src/port/snprintf.c. Before that, on most platforms we're at the mercy of the local libc, but it appears that Solaris 10 is the only supported platform where we'd still get a crash. Most other platforms such as *BSD, macOS, and Solaris 11 have adopted glibc's behavior at some point. (AIX and HPUX just print "" not "(null)", but that's close enough.) I've not checked what Windows' native printf would do, but it doesn't matter because we've long used snprintf.c on that platform. In v12 and up, also const-ify related code so that we're not casting away const on the constant string. This is just neatnik-ism, since next to no compilers will warn about that. Discussion: https://postgr.es/m/17098-b960f3616c861f83@postgresql.org
* jit: Don't inline functions that access thread-locals.Thomas Munro2021-07-22
| | | | | | | | | | | | Code inlined by LLVM can crash or fail with "Relocation type not implemented yet!" if it tries to access thread local variables. Don't inline such code. Back-patch to 11, where LLVM arrived. Bug #16696. Author: Dmitry Marakasov <amdmi3@amdmi3.ru> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/16696-29d944a33801fbfe@postgresql.org
* Doc: improve documentation about exponentiation operator.Tom Lane2021-07-21
| | | | | | | | | | Now that we're not having to wedge this into the straitjacket of the old operator table format, we can add another example to clarify the point about left-to-right associativity. Per suggestion from mdione at grulic.org.ar. https://postgr.es/m/162661954599.693.13700316547731859171@wrigleys.postgresql.org
* Document "B" and "us" as accepted units in postgres.conf.sampleJohn Naylor2021-07-21
| | | | | | | | | | | | | | In postgresql.conf, memory and file size GUCs can be specified with "B" (bytes) as of b06d8e58b. Likewise, time GUCs can be specified with "us" (microseconds) as of caf626b2c. Update postgres.conf.sample to reflect that fact. Pavel Luzanov Backpatch to v12, which is the earliest version that allows both of these units. A separate commit will document the "B" case for v11. Discussion: https://www.postgresql.org/message-id/flat/f10d16fc-8fa0-1b3c-7371-cb3a35a13b7a%40postgrespro.ru
* doc: Document that only superusers can use pg_import_system_collations().Fujii Masao2021-07-21
| | | | | | | | Back-patch to v10 where pg_import_system_collations() was added. Author: Atsushi Torikoshi Reviewed-by: Fujii Masao Discussion: https://postgr.es/m/b7f484692a3e283710032e68b7f40617@oss.nttdata.com
* Fix corner-case uninitialized-variable issues in plpgsql.Tom Lane2021-07-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If an error was raised during our initial attempt to check whether a successfully-compiled expression is "simple", subsequent calls of exec_stmt_execsql would suppose that stmt->mod_stmt was already computed when it had not been. This could lead to assertion failures in debug builds; in production builds the effect would typically be to act as if INTO STRICT had been specified even when it had not been. Of course that only matters if the subsequent attempt to execute the expression succeeds, so that the problem can only be reached by fixing a failure in some referenced, inline-able SQL function and then retrying the calling plpgsql function in the same session. (There might be even-more-obscure ways to change the expression's behavior without changing the plpgsql function, but that one seems like the only one people would be likely to hit in practice.) The most foolproof way to fix this would be to arrange for exec_prepare_plan to not set expr->plan until we've finished the subsidiary simple-expression check. But it seems hard to do that without creating reference-count leak issues. So settle for documenting the hazard in a comment and fixing exec_stmt_execsql to test separately for whether it's computed stmt->mod_stmt. (That adds a test-and-branch per execution, but hopefully that's negligible in context.) In v11 and up, also fix exec_stmt_call which had a variant of the same issue. Per bug #17113 from Alexander Lakhin. Back-patch to all supported branches. Discussion: https://postgr.es/m/17113-077605ce00e0e7ec@postgresql.org
* Fix some issues with WAL segment opening for pg_receivewal --compressMichael Paquier2021-07-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The logic handling the opening of new WAL segments was fuzzy when using --compress if a partial, non-compressed, segment with the same base name existed in the repository storing those files. In this case, using --compress would cause the code to first check for the existence and the size of a non-compressed segment, followed by the opening of a new compressed, partial, segment. The code was accidentally working correctly on most platforms as the buildfarm has proved, except bowerbird where gzflush() could fail in this code path. It is wrong anyway to take the code path used pre-padding when creating a new partial, non-compressed, segment, so let's fix it. Note that this issue exists when users mix successive runs of pg_receivewal with or without compression, as discovered with the tests introduced by ffc9dda. While on it, this refactors the code so as code paths that need to know about the ".gz" suffix are down from four to one in walmethods.c, easing a bit the introduction of new compression methods. This addresses a second issue where log messages generated for an unexpected failure would not show the compressed segment name involved, which was confusing, printing instead the name of the non-compressed equivalent. Reported-by: Georgios Kokolatos Discussion: https://postgr.es/m/YPDLz2x3o1aX2wRh@paquier.xyz Backpatch-through: 10
* Make new replication slot test code even less racyAlvaro Herrera2021-07-19
| | | | | | | | | Further fix the test code in ead9e51e8236, this time by waiting until the checkpoint has completed before moving on; this ensures that the WAL segment removal has already happened when we create the next slot. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Discussion: https://postgr.es/m/20210719.111318.2042379313472032754.horikyota.ntt@gmail.com
* Don't allow to set replication slot_name as ''.Amit Kapila2021-07-19
| | | | | | | | | | | | | We don't allow to create replication slot_name as an empty string ('') via SQL API pg_create_logical_replication_slot() but it is allowed to be set via Alter Subscription command. This will lead to apply worker repeatedly keep trying to stream data via slot_name '' and the user is not allowed to create the slot with that name. Author: Japin Li Reviewed-By: Ranier Vilela, Amit Kapila Backpatch-through: 10, where it was introduced Discussion: https://postgr.es/m/MEYP282MB1669CBD98E721C77CA696499B61A9@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM
* doc: Mention CASCADE/RESTRICT for DROP STATISTICSMichael Paquier2021-07-19
| | | | | | | | | | This grammar has no effect as there are no dependencies on statistics, but it is supported by the parser. This is more consistent with the other DROP commands. Author: Vignesh C Discussion: https://postgr.es/m/CALDaNm1LA=yNmzcSfy+0oe6CEAgsxXRf_-UutE3ZncFi8QkFNQ@mail.gmail.com Backpatch-through: 10
* Make new replication slot test code less racyAlvaro Herrera2021-07-17
| | | | | | | | | | | The new test code added in ead9e51e8236 is racy -- it hinges on shared-memory state, which changes before the WARNING message is logged. Put it the other way around. Backpatch to 13. Author: Álvaro Herrera <alvherre@alvh.no-ip.org> Discussion: https://postgr.es/m/202107161809.zclasccpfcg3@alvherre.pgsql
* Doc: document the current-transaction-modes GUCs.Tom Lane2021-07-17
| | | | | | | | | | We had documentation of default_transaction_isolation et al, but for some reason not of transaction_isolation et al. AFAICS this is just an ancient oversight, so repair. Per bug #17077 from Yanliang Lei. Discussion: https://postgr.es/m/17077-ade8e166a01e1374@postgresql.org
* Fix pg_dump for disabled triggers on partitioned tablesAlvaro Herrera2021-07-16
| | | | | | | | | | | | | | | | pg_dump failed to preserve the 'enabled' flag (which can be not only disabled, but also REPLICA or ALWAYS) for partitions which had it changed from their respective parents. Attempt to handle that by including a definition for such triggers in the dump, but replace the standard CREATE TRIGGER line with an ALTER TRIGGER line. Backpatch to 11, where these triggers can exist. In branches 11 and 12, pick up a few test lines from commit b9b408c48724 to verify that pg_upgrade is okay with these arrangements. Co-authored-by: Justin Pryzby <pryzby@telsasoft.com> Co-authored-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Discussion: https://postgr.es/m/20200930223450.GA14848@telsasoft.com
* Preserve firing-on state when cloning row triggers to partitionsAlvaro Herrera2021-07-16
| | | | | | | | | | | | | | | When triggers are cloned from partitioned tables to their partitions, the 'tgenabled' flag (origin/replica/always/disable) was not propagated. Make it so that the flag on the trigger on partition is initially set to the same value as on the partitioned table. Add a test case to verify the behavior. Backpatch to 11, where this appeared in commit 86f575948c77. Author: Álvaro Herrera <alvherre@alvh.no-ip.org> Reported-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://postgr.es/m/20200930223450.GA14848@telsasoft.com
* Advance old-segment horizon properly after slot invalidationAlvaro Herrera2021-07-16
| | | | | | | | | | | | | | | | When some slots are invalidated due to the max_slot_wal_keep_size limit, the old segment horizon should move forward to stay within the limit. However, in commit c6550776394e we forgot to call KeepLogSeg again to recompute the horizon after invalidating replication slots. In cases where other slots remained, the limits would be recomputed eventually for other reasons, but if all slots were invalidated, the limits would not move at all afterwards. Repair. Backpatch to 13 where the feature was introduced. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Reported-by: Marcin Krupowicz <mk@071.ovh> Discussion: https://postgr.es/m/17103-004130e8f27782c9@postgresql.org
* Ensure HAVE_DECL_XXX macros in MSVC builds match those in Unix.Tom Lane2021-07-15
| | | | | | | | | | | | | | | | Autoconf's AC_CHECK_DECLS() always defines HAVE_DECL_whatever as 1 or 0, but some of the entries in msvc/Solution.pm showed such symbols as "undef" instead of 0. Fix that for consistency. There's no live bug in current usages AFAICS, but it's not hard to imagine one creeping in if more-complex #if tests get added. Back-patch to v13, which is as far back as Solution.pm contains this data. The inconsistency still exists in the manually-filled pg_config_ext.h.win32 files of older branches; but as long as the problem is only latent, it doesn't seem worth the trouble to clean things up there. Discussion: https://postgr.es/m/3185430.1626133592@sss.pgh.pa.us
* Fix unexpected error messages for various flavors of ALTER TABLEMichael Paquier2021-07-14
| | | | | | | | | | | | | | | | | | | | | Some commands of ALTER TABLE could fail with the following error: ERROR: "tab" is of the wrong type This error is unexpected, as all the code paths leading to ATWrongRelkindError() should use a supported set of relkinds to generate correct error messages. This commit closes the gap with such mistakes, by adding all the missing relkind combinations. Tests are added to check all the problems found. Note that some combinations are not used, but these are left around as it could have an impact on applications relying on this code. 2ed532e has done a much larger refactoring on HEAD to make such error messages easier to manage in the long-term, so nothing is needed there. Author: Kyotaro Horiguchi Reviewed-by: Peter Eisentraut, Ahsan Hadi, Michael Paquier Discussion: https://postgr.es/m/20210216.181415.368926598204753659.horikyota.ntt@gmail.com Backpatch-through: 11
* Robustify tuplesort's free_sort_tuple functionDavid Rowley2021-07-13
| | | | | | | | | | | 41469253e went to the trouble of removing a theoretical bug from free_sort_tuple by checking if the tuple was NULL before freeing it. Let's make this a little more robust by also setting the tuple to NULL so that should we be called again we won't end up doing a pfree on the already pfree'd tuple. Per advice from Tom Lane. Discussion: https://postgr.es/m/3188192.1626136953@sss.pgh.pa.us Backpatch-through: 9.6, same as 41469253e
* Fix theoretical bug in tuplesortDavid Rowley2021-07-13
| | | | | | | | | | | | | | | | | | | | | This fixes a theoretical bug in tuplesort.c which, if a bounded sort was used in combination with a byval Datum sort (tuplesort_begin_datum), when switching the sort to a bounded heap in make_bounded_heap(), we'd call free_sort_tuple(). The problem was that when sorting Datums of a byval type, the tuple is NULL and free_sort_tuple() would free the memory for it regardless of that. This would result in a crash. Here we fix that simply by adding a check to see if the tuple is NULL before trying to disassociate and free any memory belonging to it. The reason this bug is only theoretical is that nowhere in the current code base do we do tuplesort_set_bound() when performing a Datum sort. However, let's backpatch a fix for this as if any extension uses the code in this way then it's likely to cause problems. Author: Ronan Dunklau Discussion: https://postgr.es/m/CAApHDvpdoqNC5FjDb3KUTSMs5dg6f+XxH4Bg_dVcLi8UYAG3EQ@mail.gmail.com Backpatch-through: 9.6, oldest supported version
* doc: Fix typo in function prototypePeter Eisentraut2021-07-12
|
* Remove dead assignment to local variable.Heikki Linnakangas2021-07-12
| | | | | | | | | | | | This should have been removed in commit 7e30c186da, which split the loop into two. Only the first loop uses the 'from' variable; updating it in the second loop is bogus. It was never read after the first loop, so this was harmless and surely optimized away by the compiler, but let's be tidy. Backpatch to all supported versions. Author: Ranier Vilela Discussion: https://www.postgresql.org/message-id/CAEudQAoWq%2BAL3BnELHu7gms2GN07k-np6yLbukGaxJ1vY-zeiQ%40mail.gmail.com
generated by cgit v1.2.3 (git 2.25.1) at 2025-07-31 05:44:28 +0000