# PostgreSQL Weekly News - September 12, 2021 # PostgreSQL Product News
pg_dumpbinary 2.5, a program used to dump a PostgreSQL database in binary format, [released](https://github.com/lzlabs/pg_dumpbinary/releases/). pgBadger v11.6, a PostgreSQL log analyzer and graph tool written in Perl, [released](https://github.com/darold/pgbadger/releases/tag/v11.6). [pgagroal 1.3.0, a high-performance protocol-native connection pool for PostgreSQL, [released](https://agroal.github.io/pgagroal/release/announcement/2021/09/07/pgagroal-1.3.0.html) # PostgreSQL Jobs for September [https://archives.postgresql.org/pgsql-jobs/2021-09/](https://archives.postgresql.org/pgsql-jobs/2021-09/) # PostgreSQL in the News Planet PostgreSQL: [https://planet.postgresql.org/](https://planet.postgresql.org/) PostgreSQL Weekly News is brought to you this week by David Fetter Submit news and announcements by Sunday at 3:00pm PST8PDT to [email protected]. # Applied Patches Michaël Paquier pushed: - Remove some unused variables in TAP tests. Author: Amul Sul Discussion: [https://postgr.es/m/CAAJ_b96xuFh4JZE6p-zhLyDu7q=nbxjfb1z_yeau6t-mqab...@mail.gmail.com](https://postgr.es/m/CAAJ_b96xuFh4JZE6p-zhLyDu7q=nbxjfb1z_yeau6t-mqab...@mail.gmail.com) [https://git.postgresql.org/pg/commitdiff/5fcb23c18fe408bfc6669aa5bca2d21896f9fe90](https://git.postgresql.org/pg/commitdiff/5fcb23c18fe408bfc6669aa5bca2d21896f9fe90) - Move the shared memory size calculation to its own function. This change refactors the shared memory size calculation in CreateSharedMemoryAndSemaphores() to its own function. This is intended for use in a future change related to the setup of huge pages and shared memory with some GUCs, while useful on its own for extensions. Author: Nathan Bossart Discussion: [https://postgr.es/m/[email protected]](https://postgr.es/m/[email protected]) [https://git.postgresql.org/pg/commitdiff/0bd305ee1d427ef29f5fa4fa20567e3b3f5ff792](https://git.postgresql.org/pg/commitdiff/0bd305ee1d427ef29f5fa4fa20567e3b3f5ff792) - Clean up some code using "(expr) ? true : false". All the code paths simplified here were already using a boolean or used an expression that led to zero or one, making the extra bits unnecessary. Author: Justin Pryzby Reviewed-by: Tom Lane, Michael Paquier, Peter Smith Discussion: [https://postgr.es/m/[email protected]](https://postgr.es/m/[email protected]) [https://git.postgresql.org/pg/commitdiff/fd0625c7a9c679c0c1e896014b8f49a489c3a245](https://git.postgresql.org/pg/commitdiff/fd0625c7a9c679c0c1e896014b8f49a489c3a245) - Introduce GUC shared_memory_size. This runtime-computed GUC shows the size of the server's main shared memory area, taking into account the amount of shared memory allocated by extensions as this is calculated after processing shared_preload_libraries. Author: Nathan Bossart Discussion: [https://postgr.es/m/[email protected]](https://postgr.es/m/[email protected]) [https://git.postgresql.org/pg/commitdiff/bd1788051b02cfddcd9ef0e2fd094972f372b8fd](https://git.postgresql.org/pg/commitdiff/bd1788051b02cfddcd9ef0e2fd094972f372b8fd) - Fix compilation warning in ipci.c. A Size had better use %zu when printed. Oversight in bd17880, per buildfarm member lapwing. [https://git.postgresql.org/pg/commitdiff/aa37a439db6bd328d68ce815ab9e12467f42493b](https://git.postgresql.org/pg/commitdiff/aa37a439db6bd328d68ce815ab9e12467f42493b) - Make shared_memory_size a preset option. bd17880 set up that as a memory parameter, but the docs told a different story. A preset parameter is adapted here, as this option is compiled at startup time. Reported-by: Fujii Masao Discussion: [https://postgr.es/m/[email protected]](https://postgr.es/m/[email protected]) [https://git.postgresql.org/pg/commitdiff/3b231596ccfc6bb6564c63a574e429765c0f775e](https://git.postgresql.org/pg/commitdiff/3b231596ccfc6bb6564c63a574e429765c0f775e) Peter Eisentraut pushed: - Improve fix pkg-config files for static linking. Amend 4c2eab3a0dec2eae40892fb525830a5947a398c7 to link against the libraries without the `"_shlib"` suffix, since this is meant for static linking. [https://git.postgresql.org/pg/commitdiff/55392bc5b0e0c1a8045627bbc41b4ec7143c4cc7](https://git.postgresql.org/pg/commitdiff/55392bc5b0e0c1a8045627bbc41b4ec7143c4cc7) - Fix incorrect format placeholders. [https://git.postgresql.org/pg/commitdiff/bb1412baa5b57652ef69f7e995657d085fd308e4](https://git.postgresql.org/pg/commitdiff/bb1412baa5b57652ef69f7e995657d085fd308e4) - Disable anonymous record hash support except in special cases. Commit 01e658fa74 added hash support for row types. This also added support for hashing anonymous record types, using the same approach that the type cache uses for comparison support for record types: It just reports that it works, but it might fail at run time if a component type doesn't actually support the operation. We get away with that for comparison because most types support that. But some types don't support hashing, so the current state can result in failures at run time where the planner chooses hashing over sorting, whereas that previously worked if only sorting was an option. We do, however, want the record hashing support for path tracking in recursive unions, and the SEARCH and CYCLE clauses built on that. In that case, hashing is the only plan option. So enable that, this commit implements the following approach: The type cache does not report that hashing is available for the record type. This undoes that part of 01e658fa74. Instead, callers that require hashing no matter what can override that result themselves. This patch only touches the callers to make the aforementioned recursive query cases work, namely the parse analysis of unions, as well as the hash_array() function. Reported-by: Sait Talha Nisanci <[email protected]> Bug: #17158 Discussion: [https://www.postgresql.org/message-id/flat/17158-8a2ba823982537a4%40postgresql.org](https://www.postgresql.org/message-id/flat/17158-8a2ba823982537a4%40postgresql.org) [https://git.postgresql.org/pg/commitdiff/a3d2b1bbe904b0ca8d9fdde20f25295ff3e21f79](https://git.postgresql.org/pg/commitdiff/a3d2b1bbe904b0ca8d9fdde20f25295ff3e21f79) - Fix typo. [https://git.postgresql.org/pg/commitdiff/7390b6421a98b70554b6b5edea5d6e012dfdbbba](https://git.postgresql.org/pg/commitdiff/7390b6421a98b70554b6b5edea5d6e012dfdbbba) - Remove useless casts. Casting the argument of strVal() to (`Value *`) is useless, since strVal() already does that. Most code didn't do that anyway; this was apparently just a style that snuck into certain files. Reviewed-by: Dagfinn Ilmari Mannsåker <[email protected]> Reviewed-by: Kyotaro Horiguchi <[email protected]> Discussion: [https://www.postgresql.org/message-id/flat/[email protected]](https://www.postgresql.org/message-id/flat/[email protected]) [https://git.postgresql.org/pg/commitdiff/cbdf75bf8053f88bbae6b307f34ab057424a370f](https://git.postgresql.org/pg/commitdiff/cbdf75bf8053f88bbae6b307f34ab057424a370f) - Remove Value node struct. The Value node struct is a weird construct. It is its own node type, but most of the time, it actually has a node type of Integer, Float, String, or BitString. As a consequence, the struct name and the node type don't match most of the time, and so it has to be treated specially a lot. There doesn't seem to be any value in the special construct. There is very little code that wants to accept all Value variants but nothing else (and even if it did, this doesn't provide any convenient way to check it), and most code wants either just one particular node type (usually String), or it accepts a broader set of node types besides just Value. This change removes the Value struct and node type and replaces them by separate Integer, Float, String, and BitString node types that are proper node types and structs of their own and behave mostly like normal node types. Also, this removes the T_Null node tag, which was previously also a possible variant of Value but wasn't actually used outside of the Value contained in A_Const. Replace that by an isnull field in A_Const. Reviewed-by: Dagfinn Ilmari Mannsåker <[email protected]> Reviewed-by: Kyotaro Horiguchi <[email protected]> Discussion: [https://www.postgresql.org/message-id/flat/[email protected]](https://www.postgresql.org/message-id/flat/[email protected]) [https://git.postgresql.org/pg/commitdiff/639a86e36aaecb84faaf941dcd0b183ba0aba9e9](https://git.postgresql.org/pg/commitdiff/639a86e36aaecb84faaf941dcd0b183ba0aba9e9) - Fix `_equalA_Const`. 639a86e36aaecb84faaf941dcd0b183ba0aba9e9 neglected to make the necessary adjustments to `_equalA_Const`. Found only via `COPY_PARSE_PLAN_TREES`. [https://git.postgresql.org/pg/commitdiff/0ffbe900ce599d204536b9623291e05e965da23e](https://git.postgresql.org/pg/commitdiff/0ffbe900ce599d204536b9623291e05e965da23e) Fujii Masao pushed: - Fix typo in comments. Author: Hou Zhijie Discussion: [https://postgr.es/m/os0pr01mb5716e6a6535fdfdc5a1b004194...@os0pr01mb5716.jpnprd01.prod.outlook.com](https://postgr.es/m/os0pr01mb5716e6a6535fdfdc5a1b004194...@os0pr01mb5716.jpnprd01.prod.outlook.com) [https://git.postgresql.org/pg/commitdiff/78aa616be74a13156f4fc8db3a131f1fdc2cce47](https://git.postgresql.org/pg/commitdiff/78aa616be74a13156f4fc8db3a131f1fdc2cce47) - postgres_fdw: Allow application_name of remote connection to be set via GUC. This commit adds postgres_fdw.application_name GUC which specifies a value for application_name configuration parameter used when postgres_fdw establishes a connection to a foreign server. This GUC setting always overrides application_name option of the foreign server object. This GUC is useful when we want to specify our own application_name per remote connection. Previously application_name of a remote connection could be set basically only via options of a server object. But which meant that every session connecting to the same foreign server basically should use the same application_name. Also if we want to change the setting, we had to execute "ALTER SERVER ... OPTIONS ..." command. It was inconvenient. Author: Hayato Kuroda Reviewed-by: Masahiro Ikeda, Fujii Masao Discussion: [https://postgr.es/m/tycpr01mb5870d1e8b949daf6d3b84e02f5...@tycpr01mb5870.jpnprd01.prod.outlook.com](https://postgr.es/m/tycpr01mb5870d1e8b949daf6d3b84e02f5...@tycpr01mb5870.jpnprd01.prod.outlook.com) [https://git.postgresql.org/pg/commitdiff/449ab6350526e99d33363706b759951ebad7928e](https://git.postgresql.org/pg/commitdiff/449ab6350526e99d33363706b759951ebad7928e) - postgres_fdw: Revert unstable tests for postgres_fdw.application_name. Commit 449ab63505 added the tests that check that postgres_fdw.application_name GUC works as expected. But they were unstable and caused some buildfarm members to report the failure. This commit reverts those unstable tests. Reported-by: Tom Lane as per buildfarm Discussion: [https://postgr.es/m/[email protected]](https://postgr.es/m/[email protected]) [https://git.postgresql.org/pg/commitdiff/98dbef90eb29b13079ba3bd260b3c5818904ee86](https://git.postgresql.org/pg/commitdiff/98dbef90eb29b13079ba3bd260b3c5818904ee86) - Fix issue with WAL archiving in standby. Previously, walreceiver always closed the currently-opened WAL segment and created its archive notification file, after it finished writing the current segment up and received any WAL data that should be written into the next segment. If walreceiver exited just before any WAL data in the next segment arrived at standby, it did not create the archive notification file of the current segment even though that's known completed. This behavior could cause WAL archiving of the segment to be delayed until subsequent restartpoints or checkpoints created its notification file. To fix the issue, this commit changes walreceiver so that it creates an archive notification file of a current WAL segment immediately if that's known completed before receiving next WAL data. Back-patch to all supported branches. Reported-by: Kyotaro Horiguchi Author: Fujii Masao Reviewed-by: Kyotaro Horiguchi Discussion: [https://postgr.es/m/[email protected]](https://postgr.es/m/[email protected]) [https://git.postgresql.org/pg/commitdiff/596ba75cb11173a528c6b6ec0142a282e42b69ec](https://git.postgresql.org/pg/commitdiff/596ba75cb11173a528c6b6ec0142a282e42b69ec) - pgbench: Stop counting skipped transactions as soon as timer is exceeded. When throttling is used, transactions that lag behind schedule by more than the latency limit are counted and reported as skipped. Previously, there was the case where pgbench counted all skipped transactions even if the timer specified in -T option was exceeded. This could take a very long time to do that especially when unrealistically high rate setting in -R option caused quite a lot of transactions that lagged behind schedule. This could prevent pgbench from ending immediately, and so pgbench could look like it got stuck to users. To fix the issue, this commit changes pgbench so that it stops counting skipped transactions as soon as the timer is exceeded. The timer can make pgbench end soon even when there are lots of skipped transactions that have not been counted yet. Note that there is no guarantee that all skipped transactions are counted under -T though there is under -t. This is OK in practice because it's very unlikely to happen with realistic setting. Also this is not the issue that this commit newly introdues. There used to be the case where pgbench ended without counting all skipped transactions since before. Back-patch to v14. Per discussion, we decided not to bother back-patch to the stable branches because it's hard to imagine the issue happens in practice (with realistic setting). Author: Yugo Nagata, Fabien COELHO Reviewed-by: Greg Sabino Mullane, Fujii Masao Discussion: [https://postgr.es/m/[email protected]](https://postgr.es/m/[email protected]) [https://git.postgresql.org/pg/commitdiff/9bcbd7c581a5de3b915ef8fe0262e4abd9cb6e59](https://git.postgresql.org/pg/commitdiff/9bcbd7c581a5de3b915ef8fe0262e4abd9cb6e59) Tom Lane pushed: - Make timetz_zone() stable, and correct a bug for DYNTZ abbreviations. Historically, timetz_zone() has used time(NULL) as the reference point for deciding whether DST is active. That means its result can change intra-statement, requiring it to be marked VOLATILE (cf. 35979e6c3). But that definition is pretty inconsistent with the way we deal with timestamps elsewhere. Let's make it use the transaction start time ("now()") as the reference point instead. That lets it be marked STABLE, and also saves a kernel call per invocation. While at it, remove the function's use of pg_time_t and pg_localtime. Those are inconsistent with the other code in this area, which indeed created a bug: timetz_zone() delivered completely wrong answers if the zone was specified by a dynamic TZ abbreviation. (We need to do something about that in the back branches, but the fix will look different from this.) Aleksander Alekseev and Tom Lane Discussion: [https://postgr.es/m/CAJ7c6TOMG8zSNEZtCn5SPe+cCk3Lfxb71ZaQwT2F4T7PJ_t=k...@mail.gmail.com](https://postgr.es/m/CAJ7c6TOMG8zSNEZtCn5SPe+cCk3Lfxb71ZaQwT2F4T7PJ_t=k...@mail.gmail.com) [https://git.postgresql.org/pg/commitdiff/388e71af880d579212c2489686903c2cfdea9032](https://git.postgresql.org/pg/commitdiff/388e71af880d579212c2489686903c2cfdea9032) - Fix actively-misleading comments about the contents of struct pg_tm. pgtime.h documented the PG interpretation of tm_mon right alongside the POSIX interpretation of tm_year, with no hint that neither comment was correct throughout our code. Perhaps someday we ought to switch to using two separate struct definitions to provide a clearer indication of which semantics are in use where. But I fear the tedium-versus-safety-gain tradeoff would not be very good. Discussion: [https://postgr.es/m/CAJ7c6TOMG8zSNEZtCn5SPe+cCk3Lfxb71ZaQwT2F4T7PJ_t=k...@mail.gmail.com](https://postgr.es/m/CAJ7c6TOMG8zSNEZtCn5SPe+cCk3Lfxb71ZaQwT2F4T7PJ_t=k...@mail.gmail.com) [https://git.postgresql.org/pg/commitdiff/89dba59590fdd03799a47daf8019890d4324fbcf](https://git.postgresql.org/pg/commitdiff/89dba59590fdd03799a47daf8019890d4324fbcf) - Further fix psql query-cancel test. The query to wait for pg_sleep to be running did no such thing, because the regex pattern it used could match itself. Report: [https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=conchuela&dt=2021-09-06%2018%3A00%3A20](https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=conchuela&dt=2021-09-06%2018%3A00%3A20) [https://git.postgresql.org/pg/commitdiff/bd5846e4a9c1338ded5efcef53511f0d71f53f0e](https://git.postgresql.org/pg/commitdiff/bd5846e4a9c1338ded5efcef53511f0d71f53f0e) - Fix rewriter to set hasModifyingCTE correctly on rewritten queries. If we copy data-modifying CTEs from the original query to a replacement query (from a DO INSTEAD rule), we must set hasModifyingCTE properly in the replacement query. Failure to do this can cause various unpleasantness, such as unsafe usage of parallel plans. The code also neglected to propagate hasRecursive, though that's only cosmetic at the moment. A difficulty arises if the rule action is an INSERT...SELECT. We attach the original query's RTEs and CTEs to the sub-SELECT Query, but data-modifying CTEs are only allowed to appear in the topmost Query. For the moment, throw an error in such cases. It would probably be possible to avoid this error by attaching the CTEs to the top INSERT Query instead; but that would require a bunch of new code to adjust ctelevelsup references. Given the narrowness of the use-case, and the need to back-patch this fix, it does not seem worth the trouble for now. We can revisit this if we get field complaints. Per report from Greg Nancarrow. Back-patch to all supported branches. (The test case added here does not fail before v10, but there are plenty of places checking top-level hasModifyingCTE in 9.6, so I have no doubt that this code change is necessary there too.) Greg Nancarrow and Tom Lane Discussion: [`https://postgr.es/m/CAJcOf-f68DT=26YAMz_i0+Au3TcLO5oiHY5=fl6sfuits6r...@mail.gmail.com`](https://postgr.es/m/CAJcOf-f68DT=26YAMz_i0+Au3TcLO5oiHY5=fl6sfuits6r...@mail.gmail.com) Discussion: [https://postgr.es/m/CAJcOf-fAdj=ndkmsrhqzndm-o13ny4dl6xgcevdx5xvbbi0...@mail.gmail.com](https://postgr.es/m/CAJcOf-fAdj=ndkmsrhqzndm-o13ny4dl6xgcevdx5xvbbi0...@mail.gmail.com) [https://git.postgresql.org/pg/commitdiff/362e2dcc46195faadd3fa0ba011dd9a8e3829e7a](https://git.postgresql.org/pg/commitdiff/362e2dcc46195faadd3fa0ba011dd9a8e3829e7a) - In psql tab completion, offer spelled-out commands not abbreviations. Various psql backslash commands have both single-letter and long forms, for example \e and \edit. Previously, tab completion generally offered the single-letter form but not the long form. It seems more sensible to offer the long form, because (a) no useful completion can happen when you've already typed the single letter, and (b) if you're not so familiar with the command set as to know that, the long form is likely to be less confusing. Haiying Tang, reviewed by Dagfinn Ilmari Mannsåker and myself Discussion: [https://postgr.es/m/os0pr01mb61136018064660f095cb57a8fb...@os0pr01mb6113.jpnprd01.prod.outlook.com](https://postgr.es/m/os0pr01mb61136018064660f095cb57a8fb...@os0pr01mb6113.jpnprd01.prod.outlook.com) [https://git.postgresql.org/pg/commitdiff/7cffa2ed0c9f7f4d96bac7af5284c47e82af5ffa](https://git.postgresql.org/pg/commitdiff/7cffa2ed0c9f7f4d96bac7af5284c47e82af5ffa) - Fix misleading comments about TOAST access macros. Seems to have been my error in commit aeb1631ed. Noted by Christoph Berg. Discussion: [https://postgr.es/m/[email protected]](https://postgr.es/m/[email protected]) [https://git.postgresql.org/pg/commitdiff/490798451a3adc32b71b30e285bd99875d67fa2b](https://git.postgresql.org/pg/commitdiff/490798451a3adc32b71b30e285bd99875d67fa2b) - Avoid useless malloc/free traffic around getFormattedTypeName(). Coverity complained that one caller of getFormattedTypeName() failed to free the returned string. Which is true, but rather than fixing that one, let's get rid of this tedious and error-prone requirement. Now that getFormattedTypeName() caches its result, strdup'ing that result and expecting the caller to free it accomplishes little except to waste cycles. We do create a leak in the case where getTypes didn't make a TypeInfo for the type, but that basically shouldn't ever happen. Back-patch, as commit 6c450a861 was. This isn't a particularly interesting bug fix, but the API change seems like a hazard for future back-patching activity if we don't back-patch it. [https://git.postgresql.org/pg/commitdiff/072e2f8a62002cb01ed6c4e161442e133509349e](https://git.postgresql.org/pg/commitdiff/072e2f8a62002cb01ed6c4e161442e133509349e) - Check for relation length overrun soon enough. We don't allow relations to exceed 2^32-1 blocks, because block numbers are 32 bits and the last possible block number is reserved to mean InvalidBlockNumber. There is a check for this in mdextend, but that's really way too late, because the smgr API requires us to create a buffer for the block-to-be-added, and we do not want to have any buffer with blocknum InvalidBlockNumber. (Such a case can trigger assertions in bufmgr.c, plus I think it might confuse ReadBuffer's logic for data-past-EOF later on.) So put the check into ReadBuffer. Per report from Christoph Berg. It's been like this forever, so back-patch to all supported branches. Discussion: [https://postgr.es/m/[email protected]](https://postgr.es/m/[email protected]) [https://git.postgresql.org/pg/commitdiff/8481f99896a192e9fd57f5e1a99e255e27680a10](https://git.postgresql.org/pg/commitdiff/8481f99896a192e9fd57f5e1a99e255e27680a10) - Avoid fetching from an already-terminated plan. Some plan node types don't react well to being called again after they've already returned NULL. PortalRunSelect() has long dealt with this by calling the executor with NoMovementScanDirection if it sees that we've already run the portal to the end. However, commit ba2c6d6ce overlooked this point, so that persisting an already-fully-fetched cursor would fail if it had such a plan. Per report from Tomas Barton. Back-patch to v11, as the faulty commit was. (I've omitted a test case because the type of plan that causes a problem isn't all that stable.) Discussion: [https://postgr.es/m/CAPV2KRjd=ergvgbvo2ty20tktezzr6cysylxgn_w3eao9pf...@mail.gmail.com](https://postgr.es/m/CAPV2KRjd=ergvgbvo2ty20tktezzr6cysylxgn_w3eao9pf...@mail.gmail.com) [https://git.postgresql.org/pg/commitdiff/cba79a163267a44205e391137deb543f4f89bc8b](https://git.postgresql.org/pg/commitdiff/cba79a163267a44205e391137deb543f4f89bc8b) - Fix some anomalies with NO SCROLL cursors. We have long forbidden fetching backwards from a NO SCROLL cursor, but the prohibition didn't extend to cases in which we rewind the query altogether and then re-fetch forwards. I think the reason is that this logic was mainly meant to protect plan nodes that can't be run in the reverse direction. However, re-reading the query output is problematic if the query is volatile (which includes SELECT FOR UPDATE, not just queries with volatile functions): the re-read can produce different results, which confuses the cursor navigation logic completely. Another reason for disliking this approach is that some code paths will either fetch backwards or rewind-and-fetch-forwards depending on the distance to the target row; so that seemingly identical use-cases may or may not draw the "cursor can only scan forward" error. Hence, let's clean things up by disallowing rewind as well as fetch-backwards in a NO SCROLL cursor. Ordinarily we'd only make such a definitional change in HEAD, but there is a third reason to consider this change now. Commit ba2c6d6ce created some new user-visible anomalies for non-scrollable cursors WITH HOLD, in that navigation in the cursor result got confused if the cursor had been partially read before committing. The only good way to resolve those anomalies is to forbid rewinding such a cursor, which allows removal of the incorrect cursor state manipulations that ba2c6d6ce added to PersistHoldablePortal. To minimize the behavioral change in the back branches (including v14), refuse to rewind a NO SCROLL cursor only when it has a holdStore, ie has been held over from a previous transaction due to WITH HOLD. This should avoid breaking most applications that have been sloppy about whether to declare cursors as scrollable. We'll enforce the prohibition across-the-board beginning in v15. Back-patch to v11, as ba2c6d6ce was. Discussion: [https://postgr.es/m/[email protected]](https://postgr.es/m/[email protected]) [https://git.postgresql.org/pg/commitdiff/c1b7a6c2731241cf5af4c08de54a64fc8999d727](https://git.postgresql.org/pg/commitdiff/c1b7a6c2731241cf5af4c08de54a64fc8999d727) - Make pg_regexec() robust against out-of-range search_start. If search_start is greater than the length of the string, we should just return REG_NOMATCH immediately. (Note that the equality case should *not* be rejected, since the pattern might be able to match zero characters.) This guards various internal assumptions that the min of a range of string positions is not more than the max. Violation of those assumptions could allow an attempt to fetch string[search_start-1], possibly causing a crash. Jaime Casanova pointed out that this situation is reachable with the new regexp_xxx functions that accept a user-specified start position. I don't believe it's reachable via any in-core call site in v14 and below. However, extensions could possibly call pg_regexec with an out-of-range search_start, so let's back-patch the fix anyway. Discussion: [https://postgr.es/m/20210911180357.GA6870@ahch-to](https://postgr.es/m/20210911180357.GA6870@ahch-to) [https://git.postgresql.org/pg/commitdiff/e757080e041214cf6983e3e77ef01e83f1371d72](https://git.postgresql.org/pg/commitdiff/e757080e041214cf6983e3e77ef01e83f1371d72) Álvaro Herrera pushed: - Add PublicationTable and PublicationRelInfo structs. These encapsulate a relation when referred from replication DDL. Currently they don't do anything useful (they're just wrappers around RangeVar and Relation respectively) but in the future they'll be used to carry column lists. Extracted from a larger patch by Rahila Syed. Author: Rahila Syed <[email protected]> Reviewed-by: Álvaro Herrera <[email protected]> Reviewed-by: Tomas Vondra <[email protected]> Reviewed-by: Amit Kapila <[email protected]> Discussion: [`https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektnrh8nj1jf...@mail.gmail.com`](https://postgr.es/m/CAH2L28vddB_NFdRVpuyRBJEBWjz4BSyTB=_ektnrh8nj1jf...@mail.gmail.com) [https://git.postgresql.org/pg/commitdiff/0c6828fa987b791744b9c8685aadf1baa21f8977](https://git.postgresql.org/pg/commitdiff/0c6828fa987b791744b9c8685aadf1baa21f8977) Noah Misch pushed: - AIX: Fix missing libpq symbols by respecting SHLIB_EXPORTS. We make each AIX shared library export all globals found in .o files that originate in the library. That doesn't include symbols acquired by -lpgcommon_shlib. That is good on average, but it became a problem for libpq when commit e6afa8918c461c1dd80c5063a950518fa4e950cd moved five official libpq API symbols into src/common. Fix this by implementing the SHLIB_EXPORTS mechanism for AIX, so affected libraries export the same symbols that they export on Linux. This reintroduces symbols pg_encoding_to_char, pg_utf_mblen, pg_char_to_encoding, pg_valid_server_encoding, and pg_valid_server_encoding_id. Back-patch to v13, where the aforementioned commit first appeared. While a minor release is usually the wrong time to add or remove symbol exports in libpq or libecpg, we should expect users to want each documented symbol. Tony Reix Discussion: [https://postgr.es/m/pr3pr02mb6396742e2fc3e77d37a920bc86...@pr3pr02mb6396.eurprd02.prod.outlook.com](https://postgr.es/m/pr3pr02mb6396742e2fc3e77d37a920bc86...@pr3pr02mb6396.eurprd02.prod.outlook.com) [https://git.postgresql.org/pg/commitdiff/8670b9b999adb66e2e063225496962763c4c28de](https://git.postgresql.org/pg/commitdiff/8670b9b999adb66e2e063225496962763c4c28de) - Revoke PUBLIC CREATE from public schema, now owned by pg_database_owner. This switches the default ACL to what the documentation has recommended since CVE-2018-1058. Upgrades will carry forward any old ownership and ACL. Sites that declined the 2018 recommendation should take a fresh look. Recipes for commissioning a new database cluster from scratch may need to create a schema, grant more privileges, etc. Out-of-tree test suites may require such updates. Reviewed by Peter Eisentraut. Discussion: [https://postgr.es/m/[email protected]](https://postgr.es/m/[email protected]) [https://git.postgresql.org/pg/commitdiff/b073c3ccd06e4cb845e121387a43faa8c68a7b62](https://git.postgresql.org/pg/commitdiff/b073c3ccd06e4cb845e121387a43faa8c68a7b62) - Update src/test/kerberos to account for previous commit. [https://git.postgresql.org/pg/commitdiff/2d689f2ee4615629867c4319a35533696cd16589](https://git.postgresql.org/pg/commitdiff/2d689f2ee4615629867c4319a35533696cd16589) Amit Kapila pushed: - Log new catalog xmin candidate in LogicalIncreaseXminForSlot(). Similar to LogicalIncreaseRestartDecodingForSlot() add a debug message to LogicalIncreaseXminForSlot() reporting a new catalog_xmin candidate. This just adds additional diagnostic information during logical decoding that can aid debugging. Author: Ashutosh Bapat Reviewed-by: Masahiko Sawada, Amit Kapila Discussion: [https://postgr.es/m/CAExHW5usQWbiUz0hHOCu5twS1O9DvpcPojf6sor=8q--vuu...@mail.gmail.com](https://postgr.es/m/CAExHW5usQWbiUz0hHOCu5twS1O9DvpcPojf6sor=8q--vuu...@mail.gmail.com) [https://git.postgresql.org/pg/commitdiff/4c3478859b7359912d7e99fea702c56b1f53000c](https://git.postgresql.org/pg/commitdiff/4c3478859b7359912d7e99fea702c56b1f53000c) - Invalidate relcache for publications defined for all tables. Updates/Deletes on a relation were allowed even without replica identity after we define the publication for all tables. This would later lead to an error on subscribers. The reason was that for such publications we were not invalidating the relcache and the publication information for relations was not getting rebuilt. Similarly, we were not invalidating the relcache after dropping of such publications which will prohibit Updates/Deletes without replica identity even without any publication. Author: Vignesh C and Hou Zhijie Reviewed-by: Hou Zhijie, Kyotaro Horiguchi, Amit Kapila Backpatch-through: 10, where it was introduced Discussion: [https://postgr.es/m/CALDaNm0pF6zeWqCA8TCe2sDuwFAy8fCqba=nhampckag-ql...@mail.gmail.com](https://postgr.es/m/CALDaNm0pF6zeWqCA8TCe2sDuwFAy8fCqba=nhampckag-ql...@mail.gmail.com) [https://git.postgresql.org/pg/commitdiff/8bd534274099aabf721ca4baef2e8a3a379d7b02](https://git.postgresql.org/pg/commitdiff/8bd534274099aabf721ca4baef2e8a3a379d7b02) Heikki Linnakangas pushed: - Fix missing words in comment. Introduced by commit c3928b467a, backpatch to v14 like that one. Author: Amit Langote Discussion: [https://www.postgresql.org/message-id/CA+HiwqFQgNLS6VGntMcuJV6erBFV425xA6wBVnY=41gk4zc...@mail.gmail.com](https://www.postgresql.org/message-id/CA+HiwqFQgNLS6VGntMcuJV6erBFV425xA6wBVnY=41gk4zc...@mail.gmail.com) [https://git.postgresql.org/pg/commitdiff/6ac763f19a6556c43933c5252065a5c81cde094d](https://git.postgresql.org/pg/commitdiff/6ac763f19a6556c43933c5252065a5c81cde094d) Andres Freund pushed: - windows: Only consider us to be running as service if stderr is invalid. Previously pgwin32_is_service() would falsely return true when postgres is started from somewhere within a service, but not as a service. That is e.g. always the case with windows docker containers, which some CI services use to run windows tests in. When postgres falsely thinks its running as a service, no messages are writting to stdout / stderr. That can be very confusing and causes a few tests to fail. To fix additionally check if stderr is invalid in pgwin32_is_service(). For that to work in backend processes, pg_ctl is changed to pass down handles so that postgres can do the same check (otherwise "default" handles are created). While this problem exists in all branches, there have been no reports by users, the prospective CI usage currently is only for master, and I am not a windows expert. So doing the change in only master for now seems the sanest approach. Author: Andres Freund <[email protected]> Reviewed-By: Magnus Hagander <[email protected]> Discussion: [https://postgr.es/m/[email protected]](https://postgr.es/m/[email protected]) [https://git.postgresql.org/pg/commitdiff/76e38b37a5f179d4c9d2865ff31b79130407530b](https://git.postgresql.org/pg/commitdiff/76e38b37a5f179d4c9d2865ff31b79130407530b) Magnus Hagander pushed: - Consistently use read-only instead of "read only". This affects one message and some documentation that used the format "read only", unlike everything else that used read-only. Backpatch-through: 14 Discussion: [https://postgr.es/m/cabuevexuxkwn0ym3+wdseqsvk6crrj-hewocgvx3r4-xvx4...@mail.gmail.com](https://postgr.es/m/cabuevexuxkwn0ym3+wdseqsvk6crrj-hewocgvx3r4-xvx4...@mail.gmail.com) [https://git.postgresql.org/pg/commitdiff/d6c916f020e291b45563d4e76a649e9364cb6f2d](https://git.postgresql.org/pg/commitdiff/d6c916f020e291b45563d4e76a649e9364cb6f2d) Daniel Gustafsson pushed: - Consistently use "superuser" instead of "super user". The correct nomenclature for the highest privileged user is superuser and not "super user", this replaces the few instances where that was used erroneously. No user-visible changes are done as all changes are in comments, so no back-patching. Author: Bharath Rupireddy <[email protected]> Discussion: [https://postgr.es/m/calj2acw3sngbd8baqiarmds1y43lux3ymwo+n8aug1hrv6h...@mail.gmail.com](https://postgr.es/m/calj2acw3sngbd8baqiarmds1y43lux3ymwo+n8aug1hrv6h...@mail.gmail.com) [https://git.postgresql.org/pg/commitdiff/f7c53bb9e309cfea3206f4ed44b38eb2bd1cf726](https://git.postgresql.org/pg/commitdiff/f7c53bb9e309cfea3206f4ed44b38eb2bd1cf726)
