Skip to main content

Browse the archive

https://github.com/postgres/postgres
07 April 2024, 13:56:23 UTC
sort by:
Revision Author Date Message Commit Date
26f5391 Tom Lane 09 August 2021, 20:47:06 UTC Stamp 14beta3. 09 August 2021, 20:47:06 UTC
7f7a9c2 Peter Eisentraut 09 August 2021, 09:51:59 UTC Translation updates Source-Git-URL: git://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 1234b3cdae465246e534cc4114129f18d3c04c38 09 August 2021, 09:51:59 UTC
b5815dd David Rowley 09 August 2021, 04:46:49 UTC Doc: Fix misleading statement about VACUUM memory limits In ec34040af I added a mention that there was no point in setting maintenance_work_limit to anything higher than 1GB for vacuum, but that was incorrect as ginInsertCleanup() also looks at what maintenance_work_mem is set to during VACUUM and that's not limited to 1GB. Here I attempt to make it more clear that the limitation is only around the number of dead tuple identifiers that we can collect during VACUUM. I've also added a note to autovacuum_work_mem to mention this limitation. I didn't do that in ec34040af as I'd had some wrong-headed ideas about just limiting the maximum value for that GUC to 1GB. Author: David Rowley Discussion: https://postgr.es/m/CAApHDvpGwOAvunp-E-bN_rbAs3hmxMoasm5pzkYDbf36h73s7w@mail.gmail.com Backpatch-through: 9.6, same as ec34040af 09 August 2021, 04:46:49 UTC
c26552f David Rowley 09 August 2021, 03:46:28 UTC Use ExplainPropertyInteger for queryid in EXPLAIN This saves a few lines of code. Also add a comment to mention why we use ExplainPropertyInteger instead of ExplainPropertyUInteger given that queryid is a uint64 type. Author: David Rowley Reviewed-by: Julien Rouhaud Discussion: https://postgr.es/m/CAApHDvqhSLYpSU_EqUdN39w9Uvb8ogmHV7_3YhJ0S3aScGBjsg@mail.gmail.com Backpatch-through: 14, where this code was originally added 09 August 2021, 03:46:28 UTC
9268fc3 Bruce Momjian 09 August 2021, 01:05:46 UTC doc: mention pg_upgrade extension script Since commit e462856a7a, pg_upgrade automatically creates a script to update extensions, so mention that instead of ALTER EXTENSION. Backpatch-through: 9.6 09 August 2021, 01:05:46 UTC
c905e64 Tom Lane 08 August 2021, 19:35:30 UTC Doc: remove bogus <indexterm> items. Copy-and-pasteo in 665c5855e, evidently. The 9.6 docs toolchain whined about duplicate index entries, though our modern toolchain doesn't. In any case, these GUCs surely are not about the default settings of these values. 08 August 2021, 19:35:30 UTC
5227d99 Tom Lane 08 August 2021, 15:56:29 UTC Rethink regexp engine's backref-related compilation state. I had committer's remorse almost immediately after pushing cb76fbd7e, upon finding that removing capturing subexpressions' subREs from the data structure broke my proposed patch for REG_NOSUB optimization. Revert that data structure change. Instead, address the concern about not changing capturing subREs' endpoints by not changing the endpoints. We don't need to, because the point of that bit was just to ensure that the atom has endpoints distinct from the outer state pair that we're stringing the branch between. We already made suitable states in the parenthesized-subexpression case, so the additional ones were just useless overhead. This seems more understandable than Spencer's original coding, and it ought to be a shade faster too by saving a few state creations and arc changes. (I actually see a couple percent improvement on Jacobson's web corpus, though that's barely above the noise floor so I wouldn't put much stock in that result.) Also, fix the logic added by ea1268f63 to ensure that the subRE recorded in v->subs[subno] is exactly the one with capno == subno. Spencer's original coding recorded the child subRE of the capture node, which is okay so far as having the right endpoint states is concerned, but as of cb76fbd7e the capturing subRE itself always has those endpoints too. I think the inconsistency is confusing for the REG_NOSUB optimization. As before, backpatch to v14. Discussion: https://postgr.es/m/0203588E-E609-43AF-9F4F-902854231EE7@enterprisedb.com 08 August 2021, 15:56:29 UTC
5e6ad63 Tom Lane 08 August 2021, 02:27:02 UTC Make regexp engine's backref-related compilation state more bulletproof. Up to now, we remembered the definition of a capturing parenthesis subexpression by storing a pointer to the associated subRE node. That was okay before, because that subRE didn't get modified anymore while parsing the rest of the regexp. However, in the wake of commit ea1268f63, that's no longer true: the outer invocation of parseqatom() feels free to scribble on that subRE. This seems to work anyway, because the states we jam into the child atom in the "prepare a general-purpose state skeleton" stanza aren't really semantically different from the original endpoints of the child atom. But that would be mighty easy to break, and it's definitely not how things worked before. Between this and the issue fixed in the prior commit, it seems best to get rid of this dependence on subRE nodes entirely. We don't need the whole child subRE for future backrefs, only its starting and ending NFA states; so let's just store pointers to those. Also, in the corner case where we make an extra subRE to handle immediately-nested capturing parentheses, it seems like it'd be smart to have the extra subRE have the same begin/end states as the original child subRE does (s/s2 not lp/rp). I think that linking it from lp to rp might actually be semantically wrong, though since Spencer's original code did it that way, I'm not totally certain. Using s/s2 is certainly not wrong, in any case. Per report from Mark Dilger. Back-patch to v14 where the problematic patches came in. Discussion: https://postgr.es/m/0203588E-E609-43AF-9F4F-902854231EE7@enterprisedb.com 08 August 2021, 02:27:13 UTC
f42ea83 Tom Lane 08 August 2021, 02:05:27 UTC Fix use-after-free issue in regexp engine. Commit cebc1d34e taught parseqatom() to optimize cases where a branch contains only one, "messy", atom by getting rid of excess subRE nodes. The way we really should do that is to keep the subRE built for the "messy" child atom; but to avoid changing parseqatom's nominal API, I made it delete that node after copying its fields to the outer subRE made by parsebranch(). It seems that that actually worked at the time; but it became dangerous after ea1268f63, because that later commit allowed the lower invocation of parse() to return a subRE that was also pointed to by some v->subs[] entry. This meant we could wind up with a dangling pointer in v->subs[], allowing a later backref to misbehave, but only if that subRE struct had been reused in between. So the damage seems confined to cases like '((...))...(...\2'. To fix, do what I should have done before and modify parseqatom's API to make it possible for it to remove the caller's subRE instead of the callee's. That's safer because we know that subRE isn't complete yet, so noplace else will have a pointer to it. Per report from Mark Dilger. Back-patch to v14 where the problematic patches came in. Discussion: https://postgr.es/m/0203588E-E609-43AF-9F4F-902854231EE7@enterprisedb.com 08 August 2021, 02:27:13 UTC
51b95fb Peter Eisentraut 07 August 2021, 18:34:49 UTC pg_amcheck: Message style improvements 07 August 2021, 18:36:43 UTC
2c91590 Tom Lane 07 August 2021, 17:29:32 UTC Really fix the ambiguity in REFRESH MATERIALIZED VIEW CONCURRENTLY. 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 07 August 2021, 17:29:32 UTC
9b0d717 Peter Eisentraut 07 August 2021, 11:36:59 UTC pg_amcheck: Add missing translation markers 07 August 2021, 11:37:29 UTC
d954019 Peter Eisentraut 07 August 2021, 10:09:22 UTC Message style improvements 07 August 2021, 10:09:22 UTC
e5f6493 Tom Lane 06 August 2021, 21:32:54 UTC Don't elide casting to typmod -1. Casting a value that's already of a type with a specific typmod to an unspecified typmod doesn't do anything so far as run-time behavior is concerned. However, it really ought to change the exposed type of the expression to match. Up to now, coerce_type_typmod hasn't bothered with that, which creates gotchas in contexts such as recursive unions. If for example one side of the union is numeric(18,3), but it needs to be plain numeric to match the other side, there's no direct way to express that. This is easy enough to fix, by inserting a RelabelType to update the exposed type of the expression. However, it's a bit nervous-making to change this behavior, because it's stood for a really long time. (I strongly suspect that it's like this in part because the logic pre-dates the introduction of RelabelType in 7.0. The commit log message for 57b30e8e2 is interesting reading here.) As a compromise, we'll sneak the change into 14beta3, and consider back-patching to stable branches if no complaints emerge in the next three months. Discussion: https://postgr.es/m/CABNQVagu3bZGqiTjb31a8D5Od3fUMs7Oh3gmZMQZVHZ=uWWWfQ@mail.gmail.com 06 August 2021, 21:32:54 UTC
0325565 Dean Rasheed 06 August 2021, 20:30:25 UTC Adjust the integer overflow tests in the numeric code. 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 06 August 2021, 20:30:25 UTC
c3a135b Peter Eisentraut 06 August 2021, 20:11:02 UTC Add missing message punctuation 06 August 2021, 20:11:02 UTC
acd6b6e Peter Eisentraut 06 August 2021, 18:55:59 UTC Fix wording 06 August 2021, 18:56:18 UTC
64b7a83 Tom Lane 05 August 2021, 23:09:24 UTC Doc: remove commit 2945a488a from v14 release notes. Now that this has been back-patched, it's no longer a new feature for v14. 05 August 2021, 23:09:24 UTC
588d3f5 Etsuro Fujita 05 August 2021, 11:00:01 UTC postgres_fdw: Fix issues with generated columns in foreign tables. 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 05 August 2021, 11:00:01 UTC
ecbdbdf Dean Rasheed 05 August 2021, 08:27:35 UTC Fix division-by-zero error in to_char() with 'EEEE' format. 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 05 August 2021, 08:27:35 UTC
fa604e0 Andres Freund 05 August 2021, 02:19:44 UTC pgbench: When using pipelining only do PQconsumeInput() when necessary. Up to now we did a PQconsumeInput() for each pipelined query, asking the OS for more input - which it often won't have, as all results might already have been sent. That turns out to have a noticeable performance impact. Alvaro Herrera reviewed the idea to add the PQisBusy() check, but not this concrete patch. Author: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/20210720180039.23rivhdft3l4mayn@alap3.anarazel.de Backpatch: 14, where libpq/pgbench pipelining was introduced. 05 August 2021, 02:19:58 UTC
e8086bd Peter Geoghegan 04 August 2021, 04:53:40 UTC Make vacuum_index_cleanup reloption RELOPT_TYPE_ENUM. Oversight in commit 3499df0d, which generalized the reloption as a way of giving users a way to consistently avoid VACUUM's index bypass optimization. Per off-list report from Nikolay Shaplov. Backpatch: 14-, where index cleanup reloption was extended. 04 August 2021, 04:53:40 UTC
3a0ba31 Bruce Momjian 03 August 2021, 16:26:08 UTC C comment: correct heading of extension query Reported-by: Justin Pryzby Discussion: https://postgr.es/m/20210803161345.GZ12533@telsasoft.com Backpatch-through: 9.6 03 August 2021, 16:26:08 UTC
2c92bae Bruce Momjian 03 August 2021, 16:17:58 UTC doc: interval spill method for units greater than months 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 03 August 2021, 16:17:58 UTC
4051a77 Bruce Momjian 03 August 2021, 15:58:15 UTC pg_upgrade: warn about extensions that need updating 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 03 August 2021, 15:58:15 UTC
9f6215b Bruce Momjian 03 August 2021, 15:27:33 UTC pg_upgrade: improve docs about extension upgrades 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 03 August 2021, 15:27:33 UTC
c362570 Bruce Momjian 03 August 2021, 15:11:51 UTC doc: mention inheritance's tableoid can be used in partitioning 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 03 August 2021, 15:11:51 UTC
924e1d0 Bruce Momjian 03 August 2021, 14:57:32 UTC doc: add example of using pg_dump with GNU split and gzip 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 03 August 2021, 14:57:32 UTC
fb23408 Etsuro Fujita 02 August 2021, 03:45:01 UTC Fix oversight in commit 1ec7fca8592178281cd5cdada0f27a340fb813fc. I failed to account for the possibility that when ExecAppendAsyncEventWait() notifies multiple async-capable nodes using postgres_fdw, a preceding node might invoke process_pending_request() to process a pending asynchronous request made by a succeeding node. In that case the succeeding node should produce a tuple to return to the parent Append node from tuples fetched by process_pending_request() when notified. Repair. Per buildfarm via Michael Paquier. Back-patch to v14, like the previous commit. Thanks to Tom Lane for testing. Discussion: https://postgr.es/m/YQP0UPT8KmPiHTMs%40paquier.xyz 02 August 2021, 03:45:01 UTC
ec410c9 Tom Lane 31 July 2021, 15:50:14 UTC Use elog, not Assert, to report failure to provide an outer snapshot. 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 31 July 2021, 15:50:14 UTC
0d6b874 Dean Rasheed 31 July 2021, 10:23:48 UTC Fix corner-case errors and loss of precision in numeric_power(). 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 31 July 2021, 10:23:48 UTC
f051b87 John Naylor 30 July 2021, 17:50:23 UTC Fix range check in ECPG numeric to int conversion 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 30 July 2021, 20:28:43 UTC
99da905 Heikki Linnakangas 30 July 2021, 09:52:49 UTC Update obsolete comment that still referred to CheckpointLock CheckpointLock was removed in commit d18e75664a, and commit ce197e91d0 updated a leftover comment in CreateCheckPoint, but there was another copy of it in CreateRestartPoint still. 30 July 2021, 09:53:03 UTC
1cf7fb3 Etsuro Fujita 30 July 2021, 08:00:01 UTC postgres_fdw: Fix handling of pending asynchronous requests. A pending asynchronous request is handled by process_pending_request(), which previously not only processed an in-progress remote query but performed ExecForeignScan() to produce a tuple to return to the local server asynchronously from the result of the remote query. But that led to a server crash when executing a query or led to an "InstrStartNode called twice in a row" or "InstrEndLoop called on running node" failure when doing EXPLAIN ANALYZE of it, in cases where the plan tree for it contained multiple async-capable nodes accessing the same initplan/subplan that contained multiple async-capable nodes scanning the same foreign tables as for the parent async-capable nodes, as reported by Andrey Lepikhov. The reason is that the second step in process_pending_request() invoked when executing the initplan/subplan for one of the parent async-capable nodes caused recursive execution of the initplan/subplan for another of the parent async-capable nodes. To fix, split process_pending_request() into the two steps and postpone the second step until ForeignAsyncConfigureWait() is called for each of the pending asynchronous requests. Also, in ExecAppendAsyncEventWait() we assumed that FDWs would register at least one wait event in a WaitEventSet created there when they were called from ForeignAsyncConfigureWait() in that function, but allow FDWs to register zero wait events in the WaitEventSet; modify ExecAppendAsyncEventWait() to just return in that case. Oversight in commit 27e1f1456. Back-patch to v14 where that commit went in. Andrey Lepikhov and Etsuro Fujita Discussion: https://postgr.es/m/fe5eaa19-1704-e4a4-76ee-3b9d37ade399@postgrespro.ru 30 July 2021, 08:00:01 UTC
f4b939f Amit Kapila 30 July 2021, 02:51:59 UTC Remove unused argument in apply_handle_commit_internal(). Oversight in commit 0926e96c49. Author: Masahiko Sawada Reviewed-By: Amit Kapila Backpatch-through: 14, where it was introduced Discussion: https://postgr.es/m/CAD21AoDeScrsHhLyEPYqN3sydg6PxAPVBboK=30xJfUVihNZDA@mail.gmail.com 30 July 2021, 02:51:59 UTC
f951f6f Alvaro Herrera 29 July 2021, 21:09:06 UTC Close yet another race condition in replication slot test code 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 While at it, update one comment that was forgotten in commit d18e75664a2f. Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Discussion: https://postgr.es/m/20210729.162038.534808353849568395.horikyota.ntt@gmail.com 29 July 2021, 21:09:06 UTC
c73bba2 Daniel Gustafsson 29 July 2021, 19:39:40 UTC docs: Fix bit_count example output The returnvalue for the bit_count(::bytea) example was assuming a non-default value of standard_conforming_strings. This was fixed in the tests in commit ebedd0c78. Author: wangzk.fnstxz@fujitsu.com Discussion: https://postgr.es/m/OSZPR01MB6551FFAC1088C82C3D799BE0FAEB9@OSZPR01MB6551.jpnprd01.prod.outlook.com Backpatch-through: 14 29 July 2021, 19:39:40 UTC
43f1d2a Tom Lane 29 July 2021, 17:33:31 UTC Improve libpq's handling of OOM during error message construction. Commit ffa2e4670 changed libpq so that multiple error reports occurring during one operation (a connection attempt or query) are accumulated in conn->errorMessage, where before new ones usually replaced any prior error. At least in theory, that makes us more vulnerable to running out of memory for the errorMessage buffer. If it did happen, the user would be left with just an empty-string error report, which is pretty unhelpful. We can improve this by relying on pqexpbuffer.c's existing "broken buffer" convention to track whether we've hit OOM for the current operation's error string, and then substituting a constant "out of memory" string in the small number of places where the errorMessage is read out. While at it, apply the same method to similar OOM cases in pqInternalNotice and pqGetErrorNotice3. Back-patch to v14 where ffa2e4670 came in. In principle this could go back further; but in view of the lack of field reports, the hazard seems negligible in older branches. Discussion: https://postgr.es/m/530153.1627425648@sss.pgh.pa.us 29 July 2021, 17:33:41 UTC
c42d3d0 Andrew Dunstan 29 July 2021, 16:15:03 UTC Avoid calling TestLib::perl2host on a symlinked directory Certain versions of msys2/Windows have been observed to resolve symlinks in perl2host rather than just follow them. This defeats using a symlinked shorter path to a longer path, and makes certain tests fail. We therefore call perl2host on the parent directory of the symlink and thereafter just use that result. Apply to release 14 where the problem has been observed. 29 July 2021, 16:17:13 UTC
68011e1 Andrew Dunstan 29 July 2021, 16:15:03 UTC Make TestLib::perl2host more consistent and robust Sometimes cygpath has been observed to return a path with a trailing slash. That can cause problems, Also, make "cygpath" usage consistent with "pwd -W" with respect to the use of forward slashes. Backpatch to release 14 where the current code was introduced. 29 July 2021, 16:16:50 UTC
67445de Michael Paquier 29 July 2021, 01:59:56 UTC Add missing exit() in pg_verifybackup when failing to find pg_waldump 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 29 July 2021, 01:59:56 UTC
f2a3d74 Fujii Masao 28 July 2021, 16:30:02 UTC Update minimum recovery point on truncation during WAL replay of abort record. 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 28 July 2021, 16:33:33 UTC
fc0d9b8 John Naylor 28 July 2021, 15:22:58 UTC Disallow negative strides in date_bin() It's not clear what the semantics of negative strides would be, so throw an error instead. Per report from Bauyrzhan Sakhariyev Reviewed-by: Tom Lane, Michael Paquier Discussion: https://www.postgresql.org/message-id/CAKpL73vZmLuFVuwF26FJ%2BNk11PVHhAnQRoREFcA03x7znRoFvA%40mail.gmail.com Backpatch to v14 28 July 2021, 16:11:33 UTC
5a8a9be David Rowley 28 July 2021, 03:02:12 UTC Doc: Clarify lock levels taken during ATTACH PARTITION 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 28 July 2021, 03:02:12 UTC
ad3b40e Alvaro Herrera 27 July 2021, 19:44:12 UTC Set pg_setting.pending_restart when pertinent config lines are removed 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 27 July 2021, 19:44:12 UTC
b7ea0e8 Tom Lane 27 July 2021, 19:01:49 UTC Fix bugs in polymorphic-argument resolution for multiranges. We failed to deal with an UNKNOWN-type input for anycompatiblemultirange; that should throw an error indicating that we don't know how to resolve the multirange type. We also failed to infer the type of an anycompatiblerange output from an anycompatiblemultirange input or vice versa. Per bug #17066 from Alexander Lakhin. Back-patch to v14 where multiranges were added. Discussion: https://postgr.es/m/17066-16a37f6223a8470b@postgresql.org 27 July 2021, 19:01:49 UTC
fd90f6b Fujii Masao 27 July 2021, 16:20:16 UTC Avoid using ambiguous word "non-negative" in error messages. 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 27 July 2021, 16:21:35 UTC
5a353a2 Bruce Momjian 27 July 2021, 02:54:35 UTC doc: for various substring funcs, document if only first match Reported-by: troy@frericks.us Discussion: https://postgr.es/m/162614304115.701.2392941350859387646@wrigleys.postgresql.org Backpatch-through: 13 27 July 2021, 02:54:35 UTC
695b4a1 Bruce Momjian 27 July 2021, 02:38:14 UTC pg_resetxlog: add option to set oldest xid & use by pg_upgrade 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 27 July 2021, 02:38:14 UTC
611e424 Tomas Vondra 26 July 2021, 15:12:28 UTC psql \dX: check schema when listing statistics objects Commit ad600bba04 added psql command \dX listing extended statistics objects, but it failed to consider search_path when selecting the elements so some of the returned elements might be invisible. The visibility was already considered for tab completion (added by commit d99d58cdc8), so adding it to the query is fairly simple. Reported and fix by Justin Pryzby, regression tests by me. Backpatch to PostgreSQL 14, where \dX was introduced. Batchpatch-through: 14 Author: Justin Pryzby Reviewed-by: Tatsuro Yamada Discussion: https://postgr.es/m/c027a541-5856-75a5-0868-341301e1624b%40nttcom.co.jp_1 26 July 2021, 15:31:16 UTC
f2a37dd Michael Paquier 26 July 2021, 07:27:01 UTC doc: Fix command example to run regression tests with PGOPTIONS The documentation mentioned the use of log_checkpoints, that cannot be used in this context. This commit replaces log_checkpoints with force_parallel_mode, a developer option useful to perform checks related to parallelism. Oversight in 854434c. Author: Haiying Tang Discussion: https://postgr.es/m/OS0PR01MB6113954B883ACEB2DDC973F2FBE59@OS0PR01MB6113.jpnprd01.prod.outlook.com Backpatch-through: 14 26 July 2021, 07:27:01 UTC
e6d9544 Tom Lane 26 July 2021, 03:25:15 UTC Harden pg_stat_statements tests against CLOBBER_CACHE_ALWAYS. 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 26 July 2021, 03:25:15 UTC
dece64a David Rowley 26 July 2021, 02:56:09 UTC Fix incorrect comment for get_agg_clause_costs Adjust the header comment in get_agg_clause_costs so that it matches what the function currently does. No recursive searching has been done ever since 0a2bc5d61. It also does not determine the aggtranstype like the comment claimed. That's all done in preprocess_aggref(). preprocess_aggref also now determines the numOrderedAggs, so remove the mention that get_agg_clause_costs also calculates "counts". Normally, since this is just an adjustment of a comment it might not be worth back-patching, but since this code is new to PG14 and that version is still in beta, then it seems worth having the comments match. Discussion: https://postgr.es/m/CAApHDvrrGrTJFPELrjx0CnDtz9B7Jy2XYW3Z2BKifAWLSaJYwQ@mail.gmail.com Backpatch-though: 14 26 July 2021, 02:56:09 UTC
b0d2867 Michael Paquier 26 July 2021, 02:14:08 UTC Fix a couple of memory leaks in src/bin/pg_basebackup/ 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 26 July 2021, 02:14:08 UTC
b154ee6 Tom Lane 25 July 2021, 18:02:27 UTC Get rid of artificial restriction on hash table sizes on Windows. 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 25 July 2021, 18:02:27 UTC
3d0a463 Andres Freund 25 July 2021, 03:14:03 UTC Deduplicate choice of horizon for a relation procarray.c. 5a1e1d83022 was a minimal bug fix for dc7420c2c92. To avoid future bugs of that kind, deduplicate the choice of a relation's horizon into a new helper, GlobalVisHorizonKindForRel(). As the code in question was only introduced in dc7420c2c92 it seems worth backpatching this change as well, otherwise 14 will look different from all other branches. A different approach to this was suggested by Matthias van de Meent. Author: Andres Freund Discussion: https://postgr.es/m/20210621122919.2qhu3pfugxxp3cji@alap3.anarazel.de Backpatch: 14, like 5a1e1d83022 25 July 2021, 03:30:26 UTC
712ba6b Tom Lane 24 July 2021, 22:35:52 UTC Fix check for conflicting session- vs transaction-level locks. 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 24 July 2021, 22:35:52 UTC
89ad14c Tom Lane 24 July 2021, 17:41:17 UTC Make printf("%s", NULL) print "(null)" instead of crashing. 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 24 July 2021, 17:41:17 UTC
d5e913a Tom Lane 24 July 2021, 16:16:40 UTC Remove configure-time thread safety checking (thread_test.c). This testing was useful when it was written, nigh twenty years ago, but it seems fairly pointless for any platform built in the last dozen or more years. (Compare also the comments at 8a2121185.) Also we now have reports that the test program itself fails under ThreadSanitizer. Rather than invest effort in fixing it, let's just drop it, and assume that the few people who still care already know they need to use --disable-thread-safety. Back-patch into v14, for consistency with 8a2121185. Discussion: https://postgr.es/m/CADhDkKzPSiNvA3Hyq+wSR_icuPmazG0cFe=YnC3U-CFcYLc8Xw@mail.gmail.com 24 July 2021, 16:16:40 UTC
81322fc John Naylor 22 July 2021, 21:34:19 UTC Fix division by zero error in date_bin Bauyrzhan Sakhariyev, via Github Backpatch to v14 22 July 2021, 21:36:26 UTC
b1c1b7a Thomas Munro 22 July 2021, 02:11:17 UTC jit: Don't inline functions that access thread-locals. 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 22 July 2021, 03:08:10 UTC
227c4e5 Tom Lane 21 July 2021, 22:03:33 UTC Doc: improve documentation about exponentiation operator. 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 21 July 2021, 22:03:45 UTC
65cc77c John Naylor 21 July 2021, 14:17:07 UTC Document "B" and "us" as accepted units in postgres.conf.sample 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 21 July 2021, 14:18:04 UTC
e5cebe1 John Naylor 21 July 2021, 13:09:32 UTC Add missing check of noError parameter in euc_tw_and_big5.c Oversight in ea1b99a66 Yukun Wang Backpatch to v14 where this parameter was introduced Discussion: https://www.postgresql.org/message-id/flat/OS0PR01MB6003FCEFF0201EF21685FD33B4E39%40OS0PR01MB6003.jpnprd01.prod.outlook.com 21 July 2021, 13:09:32 UTC
9c1d56a Fujii Masao 21 July 2021, 04:52:37 UTC doc: Document that only superusers can use pg_import_system_collations(). 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 21 July 2021, 04:53:12 UTC
f8d1333 Bruce Momjian 20 July 2021, 23:37:04 UTC doc: PG 14 relnote adjustments Reported-by: Elena Indrupskaya Discussion: https://postgr.es/m/38555778-a56b-4aca-2581-e05582fc9bcf@postgrespro.ru Author: Elena Indrupskaya Backpatch-through: 14 only 20 July 2021, 23:37:04 UTC
899564e Tom Lane 20 July 2021, 17:01:48 UTC Fix corner-case uninitialized-variable issues in plpgsql. 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 20 July 2021, 17:01:48 UTC
3a0d2d0 Michael Paquier 20 July 2021, 03:12:47 UTC Fix some issues with WAL segment opening for pg_receivewal --compress 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 20 July 2021, 03:12:47 UTC
e1cdf61 Peter Geoghegan 20 July 2021, 00:20:24 UTC Doc: vacuum_multixact_failsafe_age is multixact-based. Oversight in commit 1e55e7d1, which added a wraparound failsafe mechanism to VACUUM. Backpatch: 14-, where VACUUM failsafe was introduced. 20 July 2021, 00:20:24 UTC
9a3d41a Peter Geoghegan 20 July 2021, 00:06:47 UTC vacuumdb: Correct comment about --force-index-cleanup. Commit 3499df0d added a comment that incorrectly suggested that --force-index-cleanup did not appear in the same major version as the similar --no-index-cleanup option. In fact, both options are new to PostgreSQL 14. Backpatch: 14-, where both options were introduced. 20 July 2021, 00:06:47 UTC
1e87513 Alvaro Herrera 19 July 2021, 21:21:07 UTC Make new replication slot test code even less racy 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 19 July 2021, 21:21:07 UTC
40295d1 Amit Kapila 19 July 2021, 05:24:21 UTC Don't allow to set replication slot_name as ''. 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 19 July 2021, 05:24:21 UTC
6d0dc1a Michael Paquier 19 July 2021, 03:39:50 UTC doc: Mention CASCADE/RESTRICT for DROP STATISTICS 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 19 July 2021, 03:39:50 UTC
244ad54 Alexander Korotkov 18 July 2021, 18:07:24 UTC Support for unnest(multirange) It has been spotted that multiranges lack of ability to decompose them into individual ranges. Subscription and proper expanded object representation require substantial work, and it's too late for v14. This commit provides the implementation of unnest(multirange), which is quite trivial. unnest(multirange) is defined as a polymorphic procedure. Catversion is bumped. Reported-by: Jonathan S. Katz Discussion: https://postgr.es/m/flat/60258efe-bd7e-4886-82e1-196e0cac5433%40postgresql.org Author: Alexander Korotkov Reviewed-by: Justin Pryzby, Jonathan S. Katz, Zhihong Yu, Tom Lane Reviewed-by: Alvaro Herrera 18 July 2021, 18:11:33 UTC
d8f3b02 Alvaro Herrera 17 July 2021, 17:19:17 UTC Make new replication slot test code less racy 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 17 July 2021, 17:19:17 UTC
4466b38 Tom Lane 17 July 2021, 15:52:54 UTC Doc: document the current-transaction-modes GUCs. 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 17 July 2021, 15:52:54 UTC
3c5b7c6 Alvaro Herrera 16 July 2021, 21:29:22 UTC Fix pg_dump for disabled triggers on partitioned tables 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 16 July 2021, 21:29:22 UTC
eef92de Alvaro Herrera 16 July 2021, 17:01:43 UTC Preserve firing-on state when cloning row triggers to partitions 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 16 July 2021, 17:01:43 UTC
e5bcbb1 Alvaro Herrera 16 July 2021, 16:07:30 UTC Advance old-segment horizon properly after slot invalidation 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 16 July 2021, 16:07:30 UTC
525115a Peter Eisentraut 16 July 2021, 08:35:38 UTC doc: Spell checking 16 July 2021, 10:39:23 UTC
9ffe128 Daniel Gustafsson 15 July 2021, 21:22:59 UTC docs: fix inconsistencies in markup and case Ensure to properly mark up function parameters in text with <parameter>, avoid using <acronym> for terms which aren't acronyms and properly place the ", and" in a value list. The acronym removal is a follow-up to commit fb72a7b8c3 which removed it for minmax-multi. In passing, also fix an incorrectly cased word. Author: Ekaterina Kiryanova <e.kiryanova@postgrespro.ru> Reviewed-by: Laurenz Albe <laurenz.albe@cybertec.at> Discussion: https://postgr.es/m/c050ecbc-80b2-b360-3c1d-9fe6a6a11bb5@postgrespro.ru Backpatch-through: v14 15 July 2021, 21:22:59 UTC
081e86b Tom Lane 15 July 2021, 15:00:43 UTC Ensure HAVE_DECL_XXX macros in MSVC builds match those in Unix. 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 15 July 2021, 15:00:43 UTC
4d39d4e Alexander Korotkov 15 July 2021, 11:18:19 UTC Fix small inconsistencies in catalog definition of multirange operators This commit fixes the description of a couple of multirange operators and oprjoin for another multirange operator. The change of oprjoin is more cosmetic since both old and new functions return the same constant. These cosmetic changes don't worth catalog incompatibility between 14beta2 and 14beta3. So, catversion isn't bumped. Discussion: https://postgr.es/m/CAPpHfdv9OZEuZDqOQoUKpXhq%3Dmc-qa4gKCPmcgG5Vvesu7%3Ds1w%40mail.gmail.com Backpatch-throgh: 14 15 July 2021, 11:18:53 UTC
b900635 Michael Paquier 15 July 2021, 06:00:52 UTC Remove unnecessary assertion in postmaster.c A code path asserted that the archiver was dead, but a check made that impossible to happen. Author: Bharath Rupireddy Discussion: https://postgr.es/m/CALj2ACW=CYE1ars+2XyPTEPq0wQvru4c0dPZ=Nrn3EqNBkksvQ@mail.gmail.com Backpatch-throgh: 14 15 July 2021, 06:00:52 UTC
3b57d5a Magnus Hagander 14 July 2021, 09:04:15 UTC Clarify description of pg_stat_statements columns Reported-By: Peter Eisentraut Backpatch-through: 14 Discussion: https://postgr.es/m/8f5e63b8-e8ed-0f80-d8c4-68222624c200@enterprisedb.com 14 July 2021, 09:11:11 UTC
0c83eb2 Michael Paquier 14 July 2021, 08:15:01 UTC Fix unexpected error messages for various flavors of ALTER TABLE 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 14 July 2021, 08:15:01 UTC
b4842a8 Peter Eisentraut 14 July 2021, 07:15:14 UTC Fix lack of message pluralization 14 July 2021, 07:15:35 UTC
47ca483 David Rowley 14 July 2021, 00:45:00 UTC Change the name of the Result Cache node to Memoize "Result Cache" was never a great name for this node, but nobody managed to come up with another name that anyone liked enough. That was until David Johnston mentioned "Node Memoization", which Tom Lane revised to just "Memoize". People seem to like "Memoize", so let's do the rename. Reviewed-by: Justin Pryzby Discussion: https://postgr.es/m/20210708165145.GG1176@momjian.us Backpatch-through: 14, where Result Cache was introduced 14 July 2021, 00:45:00 UTC
6201fa3 Tom Lane 13 July 2021, 19:01:01 UTC Rename debug_invalidate_system_caches_always to debug_discard_caches. The name introduced by commit 4656e3d66 was agreed to be unreasonably long. To match this change, rename initdb's recently-added --clobber-cache option to --discard-caches. Discussion: https://postgr.es/m/1374320.1625430433@sss.pgh.pa.us 13 July 2021, 19:01:01 UTC
a92709f David Rowley 13 July 2021, 01:27:44 UTC Robustify tuplesort's free_sort_tuple function 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 13 July 2021, 01:27:44 UTC
a3b8d91 David Rowley 13 July 2021, 00:42:04 UTC Fix theoretical bug in tuplesort 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 13 July 2021, 00:42:04 UTC
e75da4f Tom Lane 12 July 2021, 23:17:35 UTC Probe for preadv/pwritev in a more macOS-friendly way. Apple's mechanism for dealing with functions that are available in only some OS versions confuses AC_CHECK_FUNCS, and therefore AC_REPLACE_FUNCS. We can use AC_CHECK_DECLS instead, so long as we enable -Werror=unguarded-availability-new. This allows people compiling for macOS to control whether or not preadv/pwritev are used by setting MACOSX_DEPLOYMENT_TARGET, rather than supplying a back-rev SDK. (Of course, the latter still works, too.) James Hilliard Discussion: https://postgr.es/m/20210122193230.25295-1-james.hilliard1@gmail.com 12 July 2021, 23:17:35 UTC
9b450b1 Peter Eisentraut 12 July 2021, 20:07:35 UTC doc: Fix typo in function prototype 12 July 2021, 20:17:30 UTC
2332808 Heikki Linnakangas 12 July 2021, 08:13:33 UTC Remove dead assignment to local variable. 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 12 July 2021, 08:13:59 UTC
166fcf4 Peter Eisentraut 12 July 2021, 06:45:34 UTC doc: Make release note entries more accurate Two tsquery-related release note entries had inaccuracies in the before and after examples. Clean that up. 12 July 2021, 06:52:21 UTC
5e60237 Michael Paquier 12 July 2021, 05:46:40 UTC Revert "Fix issues with Windows' stat() for files pending on deletion" This reverts commit 54fb8c7, as per the issues reported by fairywren when it comes to MinGW because of the lack of microsoft_native_stat() there. Using just stat() for MSVC is not sufficient to take care of the concurrency problems with files pending on deletion. It may be possible to paint some __MINGW64__ in the code to switch to a different implementation of stat() in this build context, but I am not sure either if relying on the implementation of stat() in MinGW to take care of the problems we are trying to fix is enough or not. So this needs more study. Discussion: https://postgr.es/m/YOvOlfRrIO0yGtgw@paquier.xyz Backpatch-through: 14 12 July 2021, 05:46:40 UTC
de1510e Michael Paquier 12 July 2021, 04:02:45 UTC Fix issues with Windows' stat() for files pending on deletion The code introduced by bed9075 to enhance the stat() implementation on Windows for file sizes larger than 4GB fails to properly detect files pending for deletion with its method based on NtQueryInformationFile() or GetFileInformationByHandleEx(), as proved by Alexander Lakhin in a custom TAP test of his own. The method used in the implementation of open() to sleep and loop when when failing on ERROR_ACCESS_DENIED (EACCES) is showing much more stability, so switch to this method. This could still lead to issues if the permission problem stays around for much longer than the timeout of 1 second used, but that should (hopefully) never happen in performance-critical paths. Still, there could be a point in increasing the timeouts for the sake of machines that handle heavy loads. Note that WIN32's open() now uses microsoft_native_stat() as it should be similar to stat() when working around issues with concurrent file deletions. I have spent some time testing this patch with pgbench in combination of the SQL functions from genfile.c, as well as running the TAP test provided on the thread with MSVC builds, and this looks much more stable than the previous method. Author: Alexander Lakhin Reviewed-by: Tom Lane, Michael Paquier, Justin Pryzby Discussion: https://postgr.es/m/c3427edf-d7c0-ff57-90f6-b5de3bb62709@gmail.com Backpatch-through: 14 12 July 2021, 04:02:45 UTC
69dfc36 Tom Lane 11 July 2021, 16:54:24 UTC Lock the extension during ALTER EXTENSION ADD/DROP. Although we were careful to lock the object being added or dropped, we failed to get any sort of lock on the extension itself. This allowed the ALTER to proceed in parallel with a DROP EXTENSION, which is problematic for a couple of reasons. If both commands succeeded we'd be left with a dangling link in pg_depend, which would cause problems later. Also, if the ALTER failed for some reason, it might try to print the extension's name, and that could result in a crash or (in older branches) a silly error message complaining about extension "(null)". Per bug #17098 from Alexander Lakhin. Back-patch to all supported branches. Discussion: https://postgr.es/m/17098-b960f3616c861f83@postgresql.org 11 July 2021, 16:54:24 UTC
5614a0f Thomas Munro 11 July 2021, 07:50:55 UTC Fix pgbench timestamp bugs. Commit 547f04e changed pgbench to use microsecond accounting, but introduced a couple of logging and aggregation bugs: 1. We print Unix epoch timestamps so that you can correlate them with other logs, but these were inadvertently changed to use a system-dependent reference epoch. Compute Unix timestamps, and begin aggregation intervals on the boundaries of whole Unix epoch seconds, as before. 2. The user-supplied aggregation interval needed to be scaled. Back-patch to 14. Author: Fabien COELHO <coelho@cri.ensmp.fr> Author: Yugo NAGATA <nagata@sraoss.co.jp> Author: Kyotaro Horiguchi <horikyota.ntt@gmail.com> Reported-by: YoungHwan Joo <rulyox@gmail.com> Reported-by: Gregory Smith <gregsmithpgsql@gmail.com> Discussion: https://postgr.es/m/CAF7igB1r6wRfSCEAB-iZBKxkowWY6%2BdFF2jObSdd9%2BiVK%2BvHJg%40mail.gmail.com Discussion: https://postgr.es/m/CAHLJuCW_8Vpcr0%3Dt6O_gozrg3wXXWXZXDioYJd3NhvKriqgpfQ%40mail.gmail.com 11 July 2021, 08:08:49 UTC
10a0797 Jeff Davis 09 July 2021, 21:15:48 UTC Fix assign_record_type_typmod(). If an error occurred in the wrong place, it was possible to leave an unintialized entry in the hash table, leading to a crash. Fixed. Also, be more careful about the order of operations so that an allocation error doesn't leak memory in CacheMemoryContext or unnecessarily advance NextRecordTypmod. Backpatch through version 11. Earlier versions (prior to 35ea75632a5) do not exhibit the problem, because an uninitialized hash entry contains a valid empty list. Author: Sait Talha Nisanci <Sait.Nisanci@microsoft.com> Reviewed-by: Andres Freund Discussion: https://postgr.es/m/HE1PR8303MB009069D476225B9A9E194B8891779@HE1PR8303MB0090.EURPRD83.prod.outlook.com Backpatch-through: 11 10 July 2021, 17:27:07 UTC
back to top