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
c1d033f Tom Lane 27 June 2022, 20:11:56 UTC Stamp 15beta2. 27 June 2022, 20:11:56 UTC
27f953e Magnus Hagander 27 June 2022, 17:43:27 UTC Remove outdated recommendation for manual VACUUM We have had a working and tunable autovacuum for at least a decade now, so remove the recommendation to manually vacuum tables at least every night. Autovacuum is now also triggered by INSERTs, so we can also remove the recommendation to run VACUUM (ANALYZE) after lots of INSERTs or DELETEs. Instead, suggest using autovacuum by moving the respective paragraph up to where the importance of VACUUM is emphasized. Author: Laurenz Albe <laurenz.albe@cybertec.at> Reviewed-By: Magnus Hagander, Peter Geoghegan Discussion: https://postgr.es/m/6f5e3da98fec14640f389d7b84c3b413833697f4.camel@cybertec.at 27 June 2022, 17:46:23 UTC
d28e26b Peter Eisentraut 27 June 2022, 10:53:05 UTC PL/Python: Update guide to alternative expected files plpython_unicode_3.out was already removed a long time ago, so it being listed here was very out of date. plpython_types_3.out was removed with the Python 2 removal. 27 June 2022, 10:53:05 UTC
fa06a34 Peter Eisentraut 27 June 2022, 07:06:44 UTC pg_upgrade: Fix version comparison for global ICU support Reported-by: Justin Pryzby <pryzby@telsasoft.com> Discussion: https://www.postgresql.org/message-id/20220625151930.GH22452@telsasoft.com 27 June 2022, 07:09:29 UTC
401f623 Michael Paquier 27 June 2022, 06:33:39 UTC doc: Mention attribute "inherited" in pg_stats_ext[_exprs] These have been added in 269b532, but the documentation did not reflect that. Author: Noriyoshi Shinoda Reviewed-by: Justin Pryzby Discussion: https://postgr.es/m/DM4PR84MB17349C4E7D88A68264C18AF3EED69@DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM 27 June 2022, 06:33:39 UTC
3c0bcdb Peter Eisentraut 27 June 2022, 06:19:02 UTC Translation updates Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 46c120873f1e906cc8dab74d8d756417e1b367f6 27 June 2022, 06:19:02 UTC
adf6d5d Heikki Linnakangas 27 June 2022, 05:21:08 UTC Fix visibility check when XID is committed in CLOG but not in procarray. TransactionIdIsInProgress had a fast path to return 'false' if the single-item CLOG cache said that the transaction was known to be committed. However, that was wrong, because a transaction is first marked as committed in the CLOG but doesn't become visible to others until it has removed its XID from the proc array. That could lead to an error: ERROR: t_xmin is uncommitted in tuple to be updated or for an UPDATE to go ahead without blocking, before the previous UPDATE on the same row was made visible. The window is usually very short, but synchronous replication makes it much wider, because the wait for synchronous replica happens in that window. Another thing that makes it hard to hit is that it's hard to get such a commit-in-progress transaction into the single item CLOG cache. Normally, if you call TransactionIdIsInProgress on such a transaction, it determines that the XID is in progress without checking the CLOG and without populating the cache. One way to prime the cache is to explicitly call pg_xact_status() on the XID. Another way is to use a lot of subtransactions, so that the subxid cache in the proc array is overflown, making TransactionIdIsInProgress rely on pg_subtrans and CLOG checks. This has been broken ever since it was introduced in 2008, but the race condition is very hard to hit, especially without synchronous replication. There were a couple of reports of the error starting from summer 2021, but no one was able to find the root cause then. TransactionIdIsKnownCompleted() is now unused. In 'master', remove it, but I left it in place in backbranches in case it's used by extensions. Also change pg_xact_status() to check TransactionIdIsInProgress(). Previously, it only checked the CLOG, and returned "committed" before the transaction was actually made visible to other queries. Note that this also means that you cannot use pg_xact_status() to reproduce the bug anymore, even if the code wasn't fixed. Report and analysis by Konstantin Knizhnik. Patch by Simon Riggs, with the pg_xact_status() change added by me. Author: Simon Riggs Reviewed-by: Andres Freund Discussion: https://www.postgresql.org/message-id/flat/4da7913d-398c-e2ad-d777-f752cf7f0bbb%40garret.ru 27 June 2022, 05:21:08 UTC
7201cd1 Thomas Munro 26 June 2022, 22:30:15 UTC Fix relptr's encoding of the base address. Previously, we encoded both NULL and the first byte at the base address as 0. That confusion led to the assertion in commit e07d4ddc, which failed when min_dynamic_shared_memory was used. Give them distinct encodings, by switching to 1-based offsets for non-NULL pointers. Also improve macro hygiene in passing (missing/misplaced parentheses), and remove open-coded access to the raw offset value from freepage.c/h. Although e07d4ddc was back-patched to 10, the only code that actually makes use of relptr at the base address arrived in 84b1c63a, so no need to back-patch further than 14 for now. Reported-by: Justin Pryzby <pryzby@telsasoft.com> Reviewed-by: Robert Haas <robertmhaas@gmail.com> Discussion: https://postgr.es/m/20220519193839.GT19626%40telsasoft.com 26 June 2022, 23:34:26 UTC
ebc584e Tom Lane 26 June 2022, 12:58:05 UTC Harden range_table_mutator() against null RangeTblEntry.subquery. Commit 64919aaab made pull_up_simple_subquery set rte->subquery = NULL after doing the deed, so that we don't waste cycles copying a now-useless subquery tree around. This turns out to create a core dump hazard in range_table_mutator, which supposes that that field is never NULL. Apparently none of our own code invokes query_tree_mutator or range_table_mutator on the top Query after subquery pullup; but it wouldn't be surprising if outside code does, and anyway I'm working on a v16 patch that will need it. We can fix this cleanly by just getting rid of the special-case handling of this field and treating it more like all the rest. I think the special case might be left over from a time when QTW_DONT_COPY_QUERY was the default behavior, but that was eons ago. Thanks to Dean Rasheed for review. Discussion: https://postgr.es/m/545569.1656107045@sss.pgh.pa.us 26 June 2022, 12:58:05 UTC
3ab4fc5 Thomas Munro 25 June 2022, 22:40:06 UTC Don't trust signalfd() on illumos. Since commit 6a2a70a02, we've used signalfd() to receive latch wakeups when building with WAIT_USE_EPOLL (default for Linux and illumos), and our traditional self-pipe when falling back to WAIT_USE_POLL (default for other Unixes with neither epoll() nor kqueue()). Unexplained hangs and kernel panics have been reported on illumos systems, apparently linked to this use of signalfd(), leading illumos users and build farm members to have to define WAIT_USE_POLL explicitly as a work-around. A bug report exists at https://www.illumos.org/issues/13700 but no fix is available yet. Let's provide a way for illumos users to go back to self-pipes with epoll(), like releases before 14, and choose that by default. No change for Linux users. To help with development/debugging, macros WAIT_USE_{EPOLL,POLL} and WAIT_USE_{SIGNALFD,SELF_PIPE} can be defined explicitly to override the defaults. Back-patch to 14, where we started using signalfd(). Reported-by: Japin Li <japinli@hotmail.com> Reported-by: Olaf Bohlen <olbohlen@eenfach.de> (off-list) Reviewed-by: Japin Li <japinli@hotmail.com> Discussion: https://postgr.es/m/MEYP282MB1669C8D88F0997354C2313C1B6CA9%40MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM 25 June 2022, 22:55:21 UTC
00377b9 Noah Misch 25 June 2022, 16:07:41 UTC CREATE INDEX: use the original userid for more ACL checks. Commit a117cebd638dd02e5c2e791c25e43745f233111b used the original userid for ACL checks located directly in DefineIndex(), but it still adopted the table owner userid for more ACL checks than intended. That broke dump/reload of indexes that refer to an operator class, collation, or exclusion operator in a schema other than "public" or "pg_catalog". Back-patch to v10 (all supported versions), like the earlier commit. Nathan Bossart and Noah Misch Discussion: https://postgr.es/m/f8a4105f076544c180a87ef0c4822352@stmuk.bayern.de 25 June 2022, 16:07:41 UTC
2f2e24d Noah Misch 25 June 2022, 16:07:41 UTC Use --no-unlogged-table-data in t/027_stream_regress.pl. This removes the need to drop unlogged relations in the src/test/regress suite, like commit dec8ad367e46180f826d5b6dc820fbecba1b71d2 did. Reviewed by Thomas Munro. Discussion: https://postgr.es/m/39945.1650895508@sss.pgh.pa.us 25 June 2022, 16:07:41 UTC
901a9d5 Peter Eisentraut 24 June 2022, 11:03:59 UTC Remove unportable test The ssl test "IPv4 host with CIDR mask does not match" apparently has a portability problem. Some operating systems don't reject the host name specification "192.0.2.1/32" as an IP address, and that is then later rejected when the SNI is set, which results in a different error message that the test is supposed to verify. The value of the test has been questioned in the discussion, and it was suggested that removing it would be an acceptable fix, so that's what this is doing. Reported-by: Nazir Bilal Yavuz <byavuz81@gmail.com> Bug: #17522 Discussion: https://www.postgresql.org/message-id/flat/17522-bfcd5c603b5f4daa%40postgresql.org 24 June 2022, 11:03:59 UTC
1f50918 Amit Kapila 24 June 2022, 03:51:24 UTC Fix intermetent test failure in 028_row_filter.pl. The test was not waiting for the subscriber's data synchronization to happen after refreshing the publication on the subscriber side. This leads subscriber's apply worker to skip applying the changes on the corresponding relation which results in a test failure. Reported-by: Hou Zhijie, as per buildfarm Author: Hou Zhijie Reviewed-by: Masahiko Sawada, Amit Kapila Discussion: https://postgr.es/m/OS0PR01MB5716A69496A8E2F2E155DB8D94B59@OS0PR01MB5716.jpnprd01.prod.outlook.com 24 June 2022, 03:51:24 UTC
1ce3451 Amit Kapila 24 June 2022, 03:07:26 UTC Doc: clarify that tablesync ignores publish operation. This patch documents that the initial data synchronization (tablesync) for logical replication does not take into account the publication 'publish' parameter when copying the existing table data. Author: Peter Smith Reviewed-by: Shi yu, Euler Taveira, Robert Haas, Amit Kapila Discussion: https://postgr.es/m/CAHut+PtbfALjFpS2MkrvQ+wWQKByP7CNh9RtFta-r=BHEU3S3w@mail.gmail.com 24 June 2022, 03:07:26 UTC
75f2171 Peter Eisentraut 23 June 2022, 20:40:52 UTC Fix missing newline at end of message 23 June 2022, 20:53:24 UTC
52b5c53 Michael Paquier 23 June 2022, 07:42:27 UTC Fix typo in pg_publication.c Author: Peter Smith Discussion: https://postgr.es/m/CAHut+PuV2XXjC4spHXy_EOhpD6MDrmmDMWnVJLYpd1_P=2+mJw@mail.gmail.com 23 June 2022, 07:42:27 UTC
41a2b56 Peter Eisentraut 23 June 2022, 06:59:27 UTC PL/Tcl: Don't link with -lc explicitly It has been reported that PL/Tcl built on macOS with GCC >=11 crashes. The reason is that there is a hash_search() function in the operating system's libraries, and that ends up being called instead of the one in postgres. This has something to do with how the linker resolves references between the various possibilities it has been given, and somehow something changed that it is now picking that one in this configuration. We found that removing the -lc from the link command line fixes this problem. The -lc was introduced a long time ago in commit e3909672f12e0ddf3e202b824fda068ad2195ef2, and we think the reasons might be obsolete, so we decided that we'll try to just remove it and see if any problems arise. Discussion: https://www.postgresql.org/message-id/flat/a78c847a-4f79-9286-be99-e819e9e4139e%40enterprisedb.com 23 June 2022, 07:36:12 UTC
ac0e2d3 Amit Kapila 23 June 2022, 03:53:46 UTC Fix memory leak due to LogicalRepRelMapEntry.attrmap. When rebuilding the relation mapping on subscribers, we were not releasing the attribute mapping's memory which was no longer required. The attribute mapping used in logical tuple conversion was refactored in PG13 (by commit e1551f96e6) but we forgot to update the related code that frees the attribute map. Author: Hou Zhijie Reviewed-by: Amit Langote, Amit Kapila, Shi yu Backpatch-through: 10, where it was introduced Discussion: https://postgr.es/m/OSZPR01MB6310F46CD425A967E4AEF736FDA49@OSZPR01MB6310.jpnprd01.prod.outlook.com 23 June 2022, 03:53:46 UTC
ca7a0d1 Michael Paquier 23 June 2022, 01:49:20 UTC Fix two issues with HEADER MATCH in COPY 072132f0 used the attnum offset to access the raw_fields array when checking that the attribute names of the header and of the relation match, leading to incorrect results or even crashes if the attribute numbers of a relation are changed, like on a dropped attribute. This fixes the logic to use the correct attribute names for the header matching requirements. Also, this commit disallows HEADER MATCH in COPY TO as there is no validation that can be done in this case. The tests are expanded for HEADER MATCH with COPY FROM and dropped columns, with cases where a relation has a dropped and re-added column, as well as a reduced set of columns. Author: Julien Rouhaud Reviewed-by: Peter Eisentraut, Michael Paquier Discussion: https://postgr.es/m/20220607154744.vvmitnqhyxrne5ms@jrouhaud 23 June 2022, 01:49:20 UTC
eba331a Andres Freund 22 June 2022, 23:50:14 UTC pgstat: Mention pgstat_replslot.c in pgstat.c. Oversight, by me, in commit 5891c7a8ed8. Author: "Drouvot, Bertrand" <bdrouvot@amazon.com> Discussion: https://postgr.es/m/bd58e027-6598-57a2-679b-d576d17bfaa9@amazon.com 22 June 2022, 23:50:14 UTC
0b135e4 Bruce Momjian 22 June 2022, 20:59:54 UTC doc: improve wording of plpgsql RAISE format text Reported-by: pg@kirasoft.com Discussion: https://postgr.es/m/165455351426.573551.7050474465030525109@wrigleys.postgresql.org Backpatch-through: 10 22 June 2022, 20:59:54 UTC
a9a230e Bruce Momjian 22 June 2022, 18:33:26 UTC doc: clarify wording about phantom reads Reported-by: akhilhello@gmail.com Discussion: https://postgr.es/m/165222922369.669.10475917322916060899@wrigleys.postgresql.org Backpatch-through: 10 22 June 2022, 18:33:48 UTC
e243de0 Robert Haas 22 June 2022, 17:11:49 UTC amcheck: Fix incorrect use of VARATT_IS_COMPRESSED. The macro is being applied to a TOAST pointer, not a varlena header. Therefore the use of VARATT_IS_COMPRESSED() is wrong. We can check VARATT_EXTERNAL_IS_COMPRESSED(), but then we don't need the length check that follows. Report and fix by Kyotaro Horiguchi. Discussion: http://postgr.es/m/20220517.162719.1671558681467343711.horikyota.ntt@gmail.com 22 June 2022, 17:11:49 UTC
9f0b953 Peter Eisentraut 22 June 2022, 12:24:48 UTC doc: Clean up title case use 22 June 2022, 12:24:48 UTC
662dbe2 Tom Lane 21 June 2022, 16:04:11 UTC Simplify tab completion of extension versions. Second thoughts about 9cd43f6cb: given that we're staying bug-compatible with the old behavior of using double not single quotes for extension versions, we can simplify this completion code by pretending that extension versions *are* identifiers, and not using VERBATIM. Then _complete_from_query() will think that the query results are identifiers in need of quoting, and we end up with the same behavior as before. This doesn't work for Query_for_list_of_available_extension_versions_with_TO, but let's just drop that: there is no other place where we handle multi-keyword phrases that way, and it doesn't seem very desirable here either. Handle completion of "UPDATE TO" in our more usual pattern. Discussion: https://postgr.es/m/CAMkU=1yV+egSYrzWvbDY8VZ6bKEMrKbzxr-HTuiHi+wDgSUMgA@mail.gmail.com 21 June 2022, 16:04:11 UTC
75bfe74 Amit Kapila 21 June 2022, 10:09:35 UTC Fix stale values in partition map entries on subscribers. We build the partition map entries on subscribers while applying the changes for update/delete on partitions. The component relation in each entry is closed after its use so we need to update it on successive use of cache entries. This problem was there since the original commit f1ac27bfda that introduced this code but we didn't notice it till the recent commit 26b3455afa started to use the component relation of partition map cache entry. Reported-by: Tom Lane, as per buildfarm Author: Amit Langote, Hou Zhijie Reviewed-by: Amit Kapila, Shi Yu Backpatch-through: 13, where it was introduced Discussion: https://postgr.es/m/OSZPR01MB6310F46CD425A967E4AEF736FDA49@OSZPR01MB6310.jpnprd01.prod.outlook.com 21 June 2022, 10:09:35 UTC
26a6d14 Peter Eisentraut 21 June 2022, 09:21:04 UTC doc: Make some synopsis punctuation consistent 21 June 2022, 09:21:04 UTC
26b3455 Amit Kapila 21 June 2022, 02:37:43 UTC Fix partition table's REPLICA IDENTITY checking on the subscriber. In logical replication, we will check if the target table on the subscriber is updatable by comparing the replica identity of the table on the publisher with the table on the subscriber. When the target table is a partitioned table, we only check its replica identity but not for the partition tables. This leads to assertion failure while applying changes for update/delete as we expect those to succeed only when the corresponding partition table has a primary key or has a replica identity defined. Fix it by checking the replica identity of the partition table while applying changes. Reported-by: Shi Yu Author: Shi Yu, Hou Zhijie Reviewed-by: Amit Langote, Amit Kapila Backpatch-through: 13, where it was introduced Discussion: https://postgr.es/m/OSZPR01MB6310F46CD425A967E4AEF736FDA49@OSZPR01MB6310.jpnprd01.prod.outlook.com 21 June 2022, 02:37:43 UTC
2253f5b Peter Eisentraut 20 June 2022, 12:33:41 UTC Fix file references inside some SGML comments In some cases, the comments mentioning their own file or another file were not correct. Author: Josh Soref <jsoref@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CACZqfqCyhE-voJUrUkc3GQuDakfJKx1ViiCdY7B8tQwyL6727g%40mail.gmail.com 20 June 2022, 12:33:41 UTC
2adeaa8 Bruce Momjian 19 June 2022, 22:05:27 UTC relnotes: simplify wording of pg_basebackup compression item 19 June 2022, 22:05:27 UTC
660ee7b Peter Eisentraut 19 June 2022, 15:39:50 UTC Message and documentation refinements 19 June 2022, 15:39:50 UTC
9cd43f6 Tom Lane 18 June 2022, 23:45:38 UTC Fix busted tab completion of extension versions. In 02b8048ba I (tgl) got rid of the need for most tab-completion queries to return pre-quoted identifiers. But I over-hastily removed the quote_ident call from Query_for_list_of_available_extension_versions* too; those still need it, because what is returned isn't an identifier at all and will (almost?) always need quoting. Arguably we should use quote_literal here instead. But quote_ident works too and people may be used to that behavior, so stick with it. In passing, fix inconsistent omission of schema-qualification in Query_for_list_of_encodings. That's not a security issue per our current guidelines, but it ought to be like the rest. Jeff Janes Discussion: https://postgr.es/m/CAMkU=1yV+egSYrzWvbDY8VZ6bKEMrKbzxr-HTuiHi+wDgSUMgA@mail.gmail.com 18 June 2022, 23:45:38 UTC
7bd4a9e Michael Paquier 17 June 2022, 00:03:07 UTC doc: Do s/int/integer/ to describe the type of some GUC parameters Three parameters have been using "int" rather than "integer" to describe their type: auth_delay.milliseconds max_logical_replication_workers pg_prewarm.autoprewarm_interval This is inconsistent with any other integer GUCs listed in the docs (148, as far as I can see). Author: Peter Smith Discussion: https://postgr.es/m/CAHut+Pv6X5T-veN2abUDUvBxZm+SSm-9otfi3LZPGyOc6u6hiA@mail.gmail.com 17 June 2022, 00:03:07 UTC
e3fcca0 Tomas Vondra 16 June 2022, 13:02:48 UTC Revert changes in HOT handling of BRIN indexes This reverts commits 5753d4ee32 and fe60b67250 that modified HOT to ignore BRIN indexes. The commit message for 5753d4ee32 claims that: When determining whether an index update may be skipped by using HOT, we can ignore attributes indexed only by BRIN indexes. There are no index pointers to individual tuples in BRIN, and the page range summary will be updated anyway as it relies on visibility info. This is partially incorrect - it's true BRIN indexes don't point to individual tuples, so HOT chains are not an issue, but the visibitlity info is not sufficient to keep the index up to date. This can easily result in corrupted indexes, as demonstrated in the hackers thread. This does not mean relaxing the HOT restrictions for BRIN is a lost cause, but it needs to handle the two aspects (allowing HOT chains and updating the page range summaries) as separate. But that requires a major changes, and it's too late for that in the current dev cycle. Reported-by: Tomas Vondra Discussion: https://postgr.es/m/05ebcb44-f383-86e3-4f31-0a97a55634cf@enterprisedb.com 16 June 2022, 13:02:49 UTC
664da2a Michael Paquier 16 June 2022, 08:21:04 UTC Fix comment in regression tests for large objects The values assigned to INV_WRITE and INV_READ were reversed in the tests, which would be confusing when writing tests specific to read or write operations on LOs. Author: Yugo Nagata Discussion: https://postgr.es/m/20220527153028.61a4608f66abcd026fd3806f@sraoss.co.jp 16 June 2022, 08:21:04 UTC
b7658c2 Amit Kapila 16 June 2022, 03:15:07 UTC Fix data inconsistency between publisher and subscriber. We were not updating the partition map cache in the subscriber even when the corresponding remote rel is changed. Due to this data was getting incorrectly replicated for partition tables after the publisher has changed the table schema. Fix it by resetting the required entries in the partition map cache after receiving a new relation mapping from the publisher. Reported-by: Shi Yu Author: Shi Yu, Hou Zhijie Reviewed-by: Amit Langote, Amit Kapila Backpatch-through: 13, where it was introduced Discussion: https://postgr.es/m/OSZPR01MB6310F46CD425A967E4AEF736FDA49@OSZPR01MB6310.jpnprd01.prod.outlook.com 16 June 2022, 03:15:07 UTC
ffffeeb Alvaro Herrera 15 June 2022, 14:54:38 UTC Link to MVCC docs in MERGE docs In addition, this moves the new paragraph in the MVCC page upwards, for a more consistent flow; some minor markup mistakes, style issues and typos are fixed too. Per comments from Justin Pryzby. Discussion: https://postgr.es/m/20220511163350.GL19626@telsasoft.com 15 June 2022, 14:54:38 UTC
a059e15 Michael Paquier 15 June 2022, 06:36:16 UTC Re-add locally-generated files in pg_upgrade's .gitignore and Makefile This reverts the changes to pg_upgrade's Makefile and .gitignore done in 15b6d21. The TAP tests run in isolation, executing pg_upgrade in tmp_check/ in the build directory so as any files created in the execution path (reindex_hash.sql and delete_old_cluster.{sh,bat}) are never in the tree, so entries are not necessary in this case. However, not having these impacts the cleanliness of the code tree when running ./pg_upgrade directly from src/bin/pg_upgrade/. This commit adds back to .gitignore all the files generated in the execution path, and the Makefile rule to clean them up if they exist. Per gripe from Tom Lane. Discussion: https://postgr.es/m/90595.1655227384@sss.pgh.pa.us 15 June 2022, 06:36:16 UTC
5a97b13 Amit Kapila 15 June 2022, 04:22:12 UTC Fix cache look-up failures while applying changes in logical replication. While building a new attrmap which maps partition attribute numbers to remoterel's, we incorrectly update the map for dropped column attributes. Later, it caused cache look-up failure when we tried to use the map to fetch the information about attributes. This also fixes the partition map cache invalidation which was using the wrong type cast to fetch the entry. We were using stale partition map entry after invalidation which leads to the assertion or cache look-up failure. Reported-by: Shi Yu Author: Hou Zhijie, Shi Yu Reviewed-by: Amit Langote, Amit Kapila Backpatch-through: 13, where it was introduced Discussion: https://postgr.es/m/OSZPR01MB6310F46CD425A967E4AEF736FDA49@OSZPR01MB6310.jpnprd01.prod.outlook.com 15 June 2022, 04:22:12 UTC
a3ff08e Michael Paquier 15 June 2022, 02:24:52 UTC Tweak behavior of psql --single-transaction depending on ON_ERROR_STOP This commit, in completion of 157f873, forces a ROLLBACK for --single-transaction only when ON_ERROR_STOP is used when one of the steps defined by -f/-c fails. Hence, COMMIT is always used when ON_ERROR_STOP is not set, ignoring the status code of the last action taken in the set of switches specified by -c/-f (previously ROLLBACK would have been issued even without ON_ERROR_STOP if the last step failed, while COMMIT was issued if a step in-between failed as long as the last step succeeded, leading to more inconsistency). While on it, this adds much more test coverage in this area when not using ON_ERROR_STOP with multiple switch patterns involving -c and -f for query files, single queries and slash commands. The behavior of ON_ERROR_STOP is arguably a bug, but there was no much support for a backpatch to force a ROLLBACK on a step failure, so this change is done only on HEAD for now. Per discussion with Tom Lane and Kyotaro Horiguchi. Discussion: https://postgr.es/m/Yqbc8bAdwnP02na4@paquier.xyz 15 June 2022, 02:24:52 UTC
ba412c9 Tom Lane 14 June 2022, 22:16:46 UTC Avoid ecpglib core dump with out-of-order operations. If an application executed operations like EXEC SQL PREPARE without having first established a database connection, it could get a core dump instead of the expected clean failure. This occurred because we did "pthread_getspecific(actual_connection_key)" without ever having initialized the TSD key actual_connection_key. The results of that are probably platform-specific, but at least on Linux it often leads to a crash. To fix, add calls to ecpg_pthreads_init() in the code paths that might use actual_connection_key uninitialized. It's harmless (and hopefully inexpensive) to do that more than once. Per bug #17514 from Okano Naoki. The problem's ancient, so back-patch to all supported branches. Discussion: https://postgr.es/m/17514-edd4fad547c5692c@postgresql.org 14 June 2022, 22:16:46 UTC
d26ac35 Tom Lane 14 June 2022, 21:47:09 UTC Doc: clarify the default collation behavior of domains. The previous wording was "the underlying data type's default collation is used", which is wrong or at least misleading. The domain inherits the base type's collation behavior, which if "default" actually can mean that we use some non-default collation obtained from elsewhere. Per complaint from Jian He. Discussion: https://postgr.es/m/CACJufxHMR8_4WooDPjjvEdaxB2hQ5a49qthci8fpKP0MKemVRQ@mail.gmail.com 14 June 2022, 21:47:09 UTC
4e54d23 Tom Lane 13 June 2022, 18:28:05 UTC pg_upgrade: further tweaking of make_outputdirs(). Use the same error message for all cases of pathname overrun, since users aren't going to much care which one was too long. Add missing newline to said error (as pg_upgrade's version of pg_fatal requires that). Add pathname overrun checks for the individual log files, not just the directories. Remove initial newline in log files; the new scheme here guarantees that we'll never be appending to an old file. Kyotaro Horiguchi and Tom Lane Discussion: https://postgr.es/m/20220613.120551.729848632120189555.horikyota.ntt@gmail.com 13 June 2022, 18:28:05 UTC
19408aa Andrew Dunstan 12 June 2022, 13:17:17 UTC Make subscription tests pass with log_error_verbosity=verbose Recent additions to the subscription tests check for log entries, but fail to account for the possible presence of an SQL errror code, which happens if log_error_verbosity is set to 'verbose'. Add this into the regular expressions that are checked for. 12 June 2022, 13:17:17 UTC
0d932a9 Bruce Momjian 11 June 2022, 19:28:20 UTC relnotes: update word wrapping 11 June 2022, 19:28:20 UTC
4d3b4d7 Bruce Momjian 11 June 2022, 18:59:18 UTC relnotes: update AS OF date 11 June 2022, 18:59:18 UTC
9dcae64 Bruce Momjian 11 June 2022, 18:37:50 UTC relnotes: add links to the release notes, indent, word wrap 11 June 2022, 18:37:50 UTC
d43cafa Bruce Momjian 10 June 2022, 17:40:50 UTC relnotes: add markup of text Doc link additions coming 10 June 2022, 17:40:50 UTC
1218780 Tom Lane 10 June 2022, 14:35:57 UTC Un-break whole-row Vars referencing domain-over-composite types. In commit ec62cb0aa, I foolishly replaced ExecEvalWholeRowVar's lookup_rowtype_tupdesc_domain call with just lookup_rowtype_tupdesc, because I didn't see how a domain could be involved there, and there were no regression test cases to jog my memory. But the existing code was correct, so revert that change and add a test case showing why it's necessary. (Note: per comment in struct DatumTupleFields, it is correct to produce an output tuple that's labeled with the base composite type, not the domain; hence just blindly looking through the domain is correct here.) Per bug #17515 from Dan Kubb. Back-patch to v11 where domains over composites became a thing. Discussion: https://postgr.es/m/17515-a24737438363aca0@postgresql.org 10 June 2022, 14:35:57 UTC
2172455 Peter Eisentraut 10 June 2022, 04:05:08 UTC Fix collation of JSON_TABLE output columns The output columns of JSON_TABLE should have the collations of their data type. The existing implementation sets the default collation if the type is collatable. Reviewed-by: Andrew Dunstan <andrew@dunslane.net> Discussion: https://www.postgresql.org/message-id/flat/9d75ce67-0121-5050-5bec-bf5009db55ce%40enterprisedb.com 10 June 2022, 04:05:08 UTC
4a8a5dd Etsuro Fujita 09 June 2022, 10:30:00 UTC Improve comments for trivial_subqueryscan(). This function can be called from mark_async_capable_plan(), a helper function for create_append_plan(), before set_subqueryscan_references(), to determine the triviality of a SubqueryScan that is a child of an Append plan node, which is done before doing finalize_plan() on the SubqueryScan (if necessary) and set_plan_references() on the subplan, unlike when called from set_subqueryscan_references(). The reason why this is safe wouldn't be that obvious, so add comments explaining this. Follow-up for commit c2bb02bc2. Reviewed by Zhihong Yu. Discussion: https://postgr.es/m/CAPmGK17%2BGiJBthC6va7%2B9n6t75e-M1N0U18YB2G1B%2BE5OdrNTA%40mail.gmail.com 09 June 2022, 10:30:00 UTC
e77de23 Peter Eisentraut 09 June 2022, 06:49:13 UTC psql: Show notices immediately (again) The new show-all-results feature in psql (7844c9918) went out of its way to show notices next to the results of the statements (in a multi-statement string) that caused them. This also had the consequence that notices for a single statement were not shown until after the statement had executed, instead of right away. After some discussion, it seems very difficult to satisfy both of these goals, so here we are giving up on the first goal and just show the notices as we get them. This restores the pre-7844c9918 behavior for notices. Reported-by: Alastair McKinley <a.mckinley@analyticsengines.com> Author: Fabien COELHO <coelho@cri.ensmp.fr> Discussion: https://www.postgresql.org/message-id/flat/PAXPR02MB760039506C87A2083AD85575E3DA9%40PAXPR02MB7600.eurprd02.prod.outlook.com 09 June 2022, 06:49:13 UTC
7ab5b4e Tom Lane 08 June 2022, 17:26:18 UTC Be more careful about GucSource for internally-driven GUC settings. The original advice for hard-wired SetConfigOption calls was to use PGC_S_OVERRIDE, particularly for PGC_INTERNAL GUCs. However, that's really overkill for PGC_INTERNAL GUCs, since there is no possibility that we need to override a user-provided setting. Instead use PGC_S_DYNAMIC_DEFAULT in most places, so that the value will appear with source = 'default' in pg_settings and thereby not be shown by psql's new \dconfig command. The one exception is that when changing in_hot_standby in a hot-standby session, we still use PGC_S_OVERRIDE, because people felt that seeing that in \dconfig would be a good thing. Similarly use PGC_S_DYNAMIC_DEFAULT for the auto-tune value of wal_buffers (if possible, that is if wal_buffers wasn't explicitly set to -1), and for the typical 2MB value of max_stack_depth. In combination these changes remove four not-very-interesting entries from the typical output of \dconfig, all of which people fingered as "why is that showing up?" in the discussion thread. Discussion: https://postgr.es/m/3118455.1649267333@sss.pgh.pa.us 08 June 2022, 17:26:18 UTC
abed46a Tom Lane 08 June 2022, 16:01:51 UTC Doc: copy-edit "jsonb Indexing" section. The patch introducing jsonpath dropped a para about that between two related examples, and didn't bother updating the introductory sentences that it falsified. The grammar was pretty shaky as well. 08 June 2022, 16:01:51 UTC
b46e8a8 Peter Eisentraut 08 June 2022, 13:35:44 UTC Put option listing back into alphabetical order 08 June 2022, 13:35:44 UTC
ca899d9 Michael Paquier 08 June 2022, 02:24:06 UTC Fix portability issue in TAP tests of psql for locales Some locales use a comma as decimal separator (like Czech or French), and psql's 001_basic.pl for \timing was not able to handle that properly. This fixes the matching regexes to be able to handle both comma and dot as possible decimal separators, as per a suggestion from Andrew Dunstan. psql tests were the only place with such a portability issue (check-world passed here with a forced LANG/LANGUAGE). These tests are new as of c0280bc, so there is no need for a backpatch. Reported-by: Pavel Stehule Discussion: https://postgr.es/m/CAFj8pRBz8iQmd2aOaCLvO-rJY6vZr-h6Q0qvV0J+yb78J7uiaA@mail.gmail.com 08 June 2022, 02:24:06 UTC
4fff78f Michael Paquier 08 June 2022, 01:53:01 UTC Restructure pg_upgrade output directories for better idempotence 38bfae3 has moved the contents written to files by pg_upgrade under a new directory called pg_upgrade_output.d/ located in the new cluster's data folder, and it used a simple structure made of two subdirectories leading to a fixed structure: log/ and dump/. This design has made weaker pg_upgrade on repeated calls, as we could get failures when creating one or more of those directories, while potentially losing the logs of a previous run (logs are retained automatically on failure, and cleaned up on success unless --retain is specified). So a user would need to clean up pg_upgrade_output.d/ as an extra step for any repeated calls of pg_upgrade. The most common scenario here is --check followed by the actual upgrade, but one could see a failure when specifying an incorrect input argument value. Removing entirely the logs would have the disadvantage of removing all the past information, even if --retain was specified at some past step. This result is annoying for a lot of users and automated upgrade flows. So, rather than requiring a manual removal of pg_upgrade_output.d/, this redesigns the set of output directories in a more dynamic way, based on a suggestion from Tom Lane and Daniel Gustafsson. pg_upgrade_output.d/ is still the base path, but a second directory level is added, mostly named after an ISO-8601-formatted timestamp (in short human-readable, with milliseconds appended to the name to avoid any conflicts). The logs and dumps are saved within the same subdirectories as previously, as of log/ and dump/, but these are located inside the subdirectory named after the timestamp. The logs of a given run are removed only after a successful run if --retain is not used, and pg_upgrade_output.d/ is kept if there are any logs from a previous run. Note that previously, pg_upgrade would have kept the logs even after a successful --check but that was inconsistent compared to the case without --check when using --retain. The code in charge of the removal of the output directories is now refactored into a single routine. Two TAP tests are added with some --check commands (one failure case and one success case), to look after the issue fixed here. Note that the tests had to be tweaked a bit to fit with the new directory structure so as it can find any logs generated on failure. This is still going to require a change in the buildfarm client for the case where pg_upgrade is tested without the TAP test, though, but I'll tackle that with a separate patch where needed. Reported-by: Tushar Ahuja Author: Michael Paquier Reviewed-by: Daniel Gustafsson, Justin Pryzby Discussion: https://postgr.es/m/77e6ecaa-2785-97aa-f229-4b6e047cbd2b@enterprisedb.com 08 June 2022, 01:53:01 UTC
fa5185b David Rowley 08 June 2022, 00:39:09 UTC Harden Memoization code against broken data types Bug #17512 highlighted that a suitably broken data type could cause the backend to crash if either the hash function or equality function were in someway non-deterministic based on their input values. Such a data type could cause a crash of the backend due to some code which assumes that we'll always find a hash table entry corresponding to an item in the Memoize LRU list. Here we remove the assumption that we'll always find the entry corresponding to the given LRU list item and add run-time checks to verify we have found the given item in the cache. This is not a fix for bug #17512, but it will turn the crash reported by that bug report into an internal ERROR. Reported-by: Ales Zeleny Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAApHDvpxFSTwvoYWT7kmFVSZ9zLAeHb=S9vrz=RExMgSkQNWqw@mail.gmail.com Backpatch-through: 14, where Memoize was added. 08 June 2022, 00:39:09 UTC
bf4717b Tom Lane 07 June 2022, 19:34:30 UTC Fix off-by-one loop termination condition in pg_stat_get_subscription(). pg_stat_get_subscription scanned one more LogicalRepWorker array entry than is really allocated. In the worst case this could lead to SIGSEGV, if the LogicalRepCtx data structure is near the end of shared memory. That seems quite unlikely though (thanks to the ordering of calls in CreateSharedMemoryAndSemaphores) and we've heard no field reports of it. A more likely misbehavior is one row of garbage data in the function's result, but even that is not real likely because of the check that the pid field matches some live backend. Report and fix by Kuntal Ghosh. This bug is old, so back-patch to all supported branches. Discussion: https://postgr.es/m/CAGz5QCJykEDzW6jQK6Yz7Qh_PMtD=95de_7QoocbVR2Qy8hWZA@mail.gmail.com 07 June 2022, 19:34:30 UTC
51da231 Tom Lane 06 June 2022, 15:26:57 UTC Don't fail on libpq-generated error reports in pg_amcheck. An error PGresult generated by libpq itself, such as a report of connection loss, won't have broken-down error fields. should_processing_continue() blithely assumed that PG_DIAG_SEVERITY_NONLOCALIZED would always be present, and would dump core if it wasn't. Per grepping to see if 6d157e7cb's mistake was repeated elsewhere. 06 June 2022, 15:26:57 UTC
6d157e7 Tom Lane 06 June 2022, 15:20:21 UTC Don't fail on libpq-generated error reports in ecpg_raise_backend(). An error PGresult generated by libpq itself, such as a report of connection loss, won't have broken-down error fields. ecpg_raise_backend() blithely assumed that PG_DIAG_MESSAGE_PRIMARY would always be present, and would end up passing a NULL string pointer to snprintf when it isn't. That would typically crash before 3779ac62d, and it would fail to provide a useful error report in any case. Best practice is to substitute PQerrorMessage(conn) in such cases, so do that. Per bug #17421 from Masayuki Hirose. Back-patch to all supported branches. Discussion: https://postgr.es/m/17421-790ff887e3188874@postgresql.org 06 June 2022, 15:20:21 UTC
157f873 Michael Paquier 06 June 2022, 02:05:59 UTC Fix psql's single transaction mode on client-side errors with -c/-f switches psql --single-transaction is able to handle multiple -c and -f switches in a single transaction since d5563d7d, but this had the surprising behavior of forcing a transaction COMMIT even if psql failed with an error in the client (for example incorrect path given to \copy), which would generate an error, but still commit any changes that were already applied in the backend. This commit makes the behavior more consistent, by enforcing a transaction ROLLBACK if any commands fail, both client-side and backend-side, so as no changes are applied if one error happens in any of them. Some tests are added on HEAD to provide some coverage about all that. Backend-side errors are unreliable as IPC::Run can complain on SIGPIPE if psql quits before reading a query result, but that should work properly in the case where any errors come from psql itself, which is what the original report is about. Reported-by: Christoph Berg Author: Kyotaro Horiguchi, Michael Paquier Discussion: https://postgr.es/m/17504-76b68018e130415e@postgresql.org Backpatch-through: 10 06 June 2022, 02:05:59 UTC
f00a4f0 Tom Lane 04 June 2022, 15:54:05 UTC Automatically count the number of output lines in psql/help.c. The hard-wired PageOutput arguments in usage() and sibling functions have been a perennial maintenance gotcha, and there's no reason to think we'll ever get any better about that. Let's get rid of those magic constants by constructing the output in a buffer where we can count the newlines before calling PageOutput. (Perhaps this is microscopically slower; but none of these functions are performance critical, and anyway we might well be buying back all the cost by avoiding having to pass most of the data through snprintf.c. I could not detect any speed difference in a desultory check.) This also gets rid of the need to assume that platform-specific variations in the output are insignificant. While at it, make the code shorter and more abstract by inventing helper macros HELP0() and HELPN() to encapsulate the specific output actions being invoked. Discussion: https://postgr.es/m/365160.1654289490@sss.pgh.pa.us 04 June 2022, 15:54:05 UTC
15b6d21 Michael Paquier 04 June 2022, 03:16:52 UTC Force run of pg_upgrade in the build directory in its TAP test TAP tests are run from their own directory in the source tree, and in a VPATH build the execution of the pg_upgrade command was leaving behind a file in the source tree, that should be left untouched. In order to avoid this issue, the test moves to PostgreSQL::Test::Utils::tmp_check, so as any files generated by pg_upgrade do not impact the source tree, but the build tree. This has as nice side-effect to make unnessary the presence of such files in pg_upgrade's .gitignore and Makefile. This strategy is similar to psql's test 010_tab_completion.pl, though the reasons behind this choice are different. In passing, fix one misleading test name that was added by 99f6f19. Per discussion with Peter Eisentraut, Andrew Dunstan, Tom Lane, Andres Freund and myself. Discussion: https://postgr.es/m/f80ace33-11fb-1cd3-20f8-98f51d151088@enterprisedb.com 04 June 2022, 03:16:52 UTC
1fbe940 Tom Lane 03 June 2022, 19:49:36 UTC Improve psql \?'s description of large-object-related commands. Provide a gloss of which command does what, as all other backslash commands have. Put the large-object command section into a more considered spot in the list. In passing, update the output-lines count in helpVariables() (oversight in 7844c9918, looks like). Thibaud Walkowiak, reviewed by Nathan Bossart and myself Discussion: https://postgr.es/m/43f0439c-df3e-a045-ac99-af33523cc2d4@dalibo.com 03 June 2022, 19:49:36 UTC
4ecacc3 Tom Lane 03 June 2022, 17:54:53 UTC Doc: improve example for intarray's uniq() function. The previous entry invited confusion between what uniq() does by itself and what it does when combined with sort(). The latter usage is pretty useful so we should show it, but add an additional example to clarify the results of uniq() alone. Per suggestion from Martin Kalcher. Back-patch to v13, where we switched to formatting that supports multiple examples. Discussion: https://postgr.es/m/165407884456.573551.8779012279828726162@wrigleys.postgresql.org 03 June 2022, 17:54:53 UTC
94c7db4 Tom Lane 03 June 2022, 15:51:37 UTC Doc: fix incorrect bit-reversal in example of macaddr formatting. Will Mortensen (minor additional copy-editing by me) Discussion: https://postgr.es/m/CAMpnoC5Y6jiZHSA82FG+e_AqkwMg-i94EYqs1C_9kXXFc3_3Yw@mail.gmail.com 03 June 2022, 15:51:37 UTC
2cc96f2 Michael Paquier 03 June 2022, 04:15:20 UTC Run tests of libpq on installcheck-world, checkprep and check-world The regression tests of libpq have been converted to a TAP test as of ac25173, but they were not run when running the global make targets mentioned in $subject as the code only considered src/interfaces/ecpg/ as a path to run. This switches to src/interfaces/, to always include the tests of libpq in each run. Reported-by: Justin Pryzby Reviewed-by: Andres Freund Discussion: https://postgr.es/m/20220529151850.GN19626@telsasoft.com 03 June 2022, 04:15:20 UTC
642e916 Etsuro Fujita 02 June 2022, 09:00:00 UTC Doc: Further fix CREATE FOREIGN TABLE synopsis. This patch fixes the partitioning synopsis in the Parameters section in the CREATE FOREIGN TABLE documentation. Follow-up for commit ce21a36cf. Back-patch to v11 where default partition was introduced. Reviewed by Amit Langote and Robert Haas. Discussion: https://postgr.es/m/CAPmGK17U5jEqVZuo3r38wB0VFWomEtJCBGn_h92HQzQ2sP-49Q%40mail.gmail.com 02 June 2022, 09:00:00 UTC
fd0b9dc Amit Kapila 02 June 2022, 03:01:50 UTC Prohibit combining publications with different column lists. Currently, we simply combine the column lists when publishing tables on multiple publications and that can sometimes lead to unexpected behavior. Say, if a column is published in any row-filtered publication, then the values for that column are sent to the subscriber even for rows that don't match the row filter, as long as the row matches the row filter for any other publication, even if that other publication doesn't include the column. The main purpose of introducing a column list is to have statically different shapes on publisher and subscriber or hide sensitive column data. In both cases, it doesn't seem to make sense to combine column lists. So, we disallow the cases where the column list is different for the same table when combining publications. It can be later extended to combine the column lists for selective cases where required. Reported-by: Alvaro Herrera Author: Hou Zhijie Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/202204251548.mudq7jbqnh7r@alvherre.pgsql 02 June 2022, 03:01:50 UTC
99f6f19 Michael Paquier 02 June 2022, 00:21:32 UTC Add missing test names in TAP tests of pg_upgrade While on it, this removes the inclusion of getcwd() as The test code does not rely on it. Author: Peter Eisentraut Discussion: https://postgr.es/m/f80ace33-11fb-1cd3-20f8-98f51d151088@enterprisedb.com 02 June 2022, 00:21:32 UTC
dd1c8dd Tom Lane 01 June 2022, 21:21:45 UTC Silence compiler warnings from some older compilers. Since a117cebd6, some older gcc versions issue "variable may be used uninitialized in this function" complaints for brin_summarize_range. Silence that using the same coding pattern as in bt_index_check_internal; arguably, a117cebd6 had too narrow a view of which compilers might give trouble. Nathan Bossart and Tom Lane. Back-patch as the previous commit was. Discussion: https://postgr.es/m/20220601163537.GA2331988@nathanxps13 01 June 2022, 21:21:45 UTC
eb39610 Tom Lane 01 June 2022, 20:15:47 UTC Fix pl/perl test case so it will still work under Perl 5.36. Perl 5.36 has reclassified the warning condition that this test case used, so that the expected error fails to appear. Tweak the test so it instead exercises a case that's handled the same way in all Perl versions of interest. This appears to meet our standards for back-patching into out-of-support branches: it changes no user-visible behavior but enables testing of old branches with newer tools. Hence, back-patch as far as 9.2. Dagfinn Ilmari Mannsåker, per report from Jitka Plesníková. Discussion: https://postgr.es/m/564579.1654093326@sss.pgh.pa.us 01 June 2022, 20:15:47 UTC
1d0de97 Tom Lane 01 June 2022, 14:39:46 UTC Doc: fix a couple of erroneous examples. The example given for anyelement <@ anymultirange didn't return true as claimed; adjust it so it does. In passing, change a couple of sample results where the modern numeric-based logic produces a different number of trailing zeroes than before. Erik Rijkers Discussion: https://postgr.es/m/cc35735d-1ec1-5bb3-9e27-cddbab7afa23@xs4all.nl 01 June 2022, 14:39:46 UTC
bbb6489 David Rowley 01 June 2022, 00:44:45 UTC Doc: mention limitation of the number of resultset columns The PostgreSQL limitations section of the documents mentioned the limit on the number of columns that can exist in a table. Users might be surprised to find that there's also a limit on the number of columns that can exist in a targetlist. Users may experience restrictions which surprise them if they happened to select a large number of columns from several tables with many columns. Here we document that there is a limitation on this and mention what that limit actually is. Wording proposal by Alvaro Herrera Reported-by: Vladimir Sitnikov Author: Dave Crammer Reviewed-by: Tom Lane Discussion: https://postgr.es/m/CAB=Je-E18aTYpNqje4mT0iEADpeGLSzwUvo3H9kRRuDdsNo4aQ@mail.gmail.com Backpatch-through: 12, where the limitations section was added 01 June 2022, 00:44:45 UTC
e1ed1a7 Magnus Hagander 31 May 2022, 19:59:47 UTC Recommend scram-sha-256 instead of md5 authentication in docs PostgreSQL 14 changed the default to be scram-sha-256, so we should stop recommending the user to use md5 or even worse password. Suggested-By: Daniel Westermann Author: Jonathan S. Katz Backpatch-through: 14 Discussion: https://postgr.es/m/GV0P278MB0419A8BAC0B0B84AFA5263D9D2DC9@GV0P278MB0419.CHEP278.PROD.OUTLOOK.COM 31 May 2022, 19:59:47 UTC
e28bb88 Alvaro Herrera 31 May 2022, 19:24:59 UTC Revert changes to CONCURRENTLY that "sped up" Xmin advance This reverts commit d9d076222f5b "VACUUM: ignore indexing operations with CONCURRENTLY". These changes caused indexes created with the CONCURRENTLY option to miss heap tuples that were HOT-updated and HOT-pruned during the index creation. Before these changes, HOT pruning would have been prevented by the Xmin of the transaction creating the index, but because this change was precisely to allow the Xmin to move forward ignoring that backend, now other backends scanning the table can prune them. This is not a problem for VACUUM (which requires a lock that conflicts with a CREATE INDEX CONCURRENTLY operation), but HOT-prune can definitely occur. In other words, Xmin advancement was sped up, but at the cost of corrupting the resulting index. Regrettably, this means that the new feature in PG14 that RIC/CIC on very large tables no longer force VACUUM to retain very old tuples goes away. We might try to implement it again in a later release, but for now the risk of indexes missing tuples is too high and there's no easy fix. Backpatch to 14, where this change appeared. Reported-by: Peter Slavov <pet.slavov@gmail.com> Diagnosys-by: Andrey Borodin <x4mmm@yandex-team.ru> Diagnosys-by: Michael Paquier <michael@paquier.xyz> Diagnosys-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/17485-396609c6925b982d%40postgresql.org 31 May 2022, 19:24:59 UTC
16c80e7 Tom Lane 31 May 2022, 18:47:44 UTC Ensure ParseTzFile() closes the input file after failing. We hadn't noticed this because (a) few people feed invalid timezone abbreviation files to the server, and (b) in typical scenarios guc.c would throw ereport(ERROR) and then transaction abort handling would silently clean up the leaked file reference. However, it was possible to observe file leakage warnings if one breaks an already-active abbreviation file, because guc.c does not throw ERROR when loading supposedly-validated settings during session start or SIGHUP processing. Report and fix by Kyotaro Horiguchi (cosmetic adjustments by me) Discussion: https://postgr.es/m/20220530.173740.748502979257582392.horikyota.ntt@gmail.com 31 May 2022, 18:47:44 UTC
c03b7f5 Tom Lane 31 May 2022, 16:18:27 UTC Doc: fix mention of psql's minimum supported server version. Commit cf0cab868 removed describe.c's support for pre-9.2 server versions, but neglected to update this documentation reference. Discussion: https://postgr.es/m/GV0P278MB041917EB3E2FE8704B5AE2C6D2DC9@GV0P278MB0419.CHEP278.PROD.OUTLOOK.COM 31 May 2022, 16:18:27 UTC
492046f Tom Lane 31 May 2022, 16:14:02 UTC Doc: fix mention of pg_dump's minimum supported server version. runtime.sgml contains a passing reference to the minimum server version that pg_dump[all] can dump from. That was 7.0 for many years, but when 64f3524e2 raised it to 8.0, we missed updating this bit. Then when 30e7c175b raised it to 9.2, we missed it again. Given that track record, I'm not too hopeful that we'll remember to fix this in future changes ... but for now, make the docs match reality in each branch. Noted by Daniel Westermann. Discussion: https://postgr.es/m/GV0P278MB041917EB3E2FE8704B5AE2C6D2DC9@GV0P278MB0419.CHEP278.PROD.OUTLOOK.COM 31 May 2022, 16:14:02 UTC
f5bfba5 Robert Haas 24 May 2022, 14:55:01 UTC shm_mq_sendv: Fix flushing bug when receiver not yet attached. With the old logic, when the reciever had not yet attached, we would never call shm_mq_inc_bytes_written(), even if force_flush = true was specified. That could result in a situation where data that the sender believes it has sent is never received. Along the way, remove a useless function prototype for a nonexistent function from shm_mq.h. Commit 46846433a03dff4f2e08c8a161e54a842da360d6 introduced these problems. Pavan Deolasee, with a few changes by me. Discussion: https://postgr.es/m/CABOikdPkwtLLCTnzzmpSMXo3QZa2yXq0J7Q61ssdLFAJYrOVvQ@mail.gmail.com 31 May 2022, 12:46:54 UTC
0a050ee Amit Kapila 31 May 2022, 09:07:41 UTC Fix typo in hash README. Author: Peter Smith Discussion: https://postgr.es/m/CAHut+Pu-V22PiJF2ym9_NVZe-+qnycfyEX24dZm=7URWhDHJ3w@mail.gmail.com 31 May 2022, 09:07:41 UTC
0efa513 Michael Paquier 31 May 2022, 00:44:00 UTC Remove useless tests for TRUNCATE on foreign tables foreign_data has kept around a set of tests for TRUNCATE to look after the case of foreign tables, with[out] inheritance and with[out] partitions, assuming that the command is not supported for this relkind. However, TRUNCATE is supported on foreign tables if the FDW involved is able to handle the command, like postgres_fdw. Note that postgres_fdw includes tests to cover all the cases removed by this commit (which had misleading comments), so these did not provide any additional coverage anyway. Author: Yugo Nagata Discussion: https://postgr.es/m/20220527172543.0a2fdb469cf048b81c0967d3@sraoss.co.jp 31 May 2022, 00:44:00 UTC
12e28aa Thomas Munro 30 May 2022, 23:38:19 UTC Add debugging help in OwnLatch(). Build farm animal gharial recently failed a few times in a parallel worker's call to OwnLatch() with "ERROR: latch already owned". Let's turn that into a PANIC and show the PID of the owner, to try to learn more. Discussion: https://postgr.es/m/CA%2BhUKGJ_0RGcr7oUNzcHdn7zHqHSB_wLSd3JyS2YC_DYB%2B-V%3Dg%40mail.gmail.com 31 May 2022, 00:06:11 UTC
5f0adec Tom Lane 30 May 2022, 18:05:20 UTC Make STRING an unreserved_keyword. Commit 1a36bc9db (SQL/JSON query functions) introduced STRING as a type_func_name_keyword, thereby breaking applications that use "string" as a table name, column name, function parameter name, etc. That seems like a pretty bad thing, not least because the SQL spec says that STRING is an unreserved keyword. This is easy enough to fix so far as the core grammar is concerned. However, doing so causes some ECPG test cases to fail, specifically those that use "string" as a typedef name. It turns out this is because portions of the ECPG grammar allow type_func_name_keywords but not unreserved_keywords as typedef names. That's pretty horrid, and it's mildly astonishing that we've not heard complaints about it before. We can fix two of those uses trivially, but the ones in the var_type production are less easy. As a stopgap, hard-code STRING as an allowed alternative in var_type. Per report from Alastair McKinley. Discussion: https://postgr.es/m/3661437.1653855582@sss.pgh.pa.us 30 May 2022, 18:05:20 UTC
a8cca60 Peter Eisentraut 30 May 2022, 05:18:57 UTC logging: Also add the command prefix to detail and hint messages This makes the output line up better and allows filtering messages by command. Discussion: https://www.postgresql.org/message-id/ba6d4fac-9e33-91f9-94fb-1e4c144a48b9@enterprisedb.com 30 May 2022, 05:26:06 UTC
b3fb16e Michael Paquier 30 May 2022, 01:50:21 UTC doc: Reword description of roles able to view track_activities's info The information generated when track_activities is accessible to superusers, roles with the privileges of pg_read_all_stats, as well as roles one has the privileges of. The original text did not outline the last point, while the change done in ac1ae47 was unclear about the second point. Per discussion with Nathan Bossart. Discussion: https://postgr.es/m/20220521185743.GA886636@nathanxps13 Backpatch-through: 10 30 May 2022, 01:50:21 UTC
fc36ac5 Heikki Linnakangas 29 May 2022, 20:53:45 UTC Fix COPY FROM when database encoding is SQL_ASCII. In the codepath when no encoding conversion is required, the check for incomplete character at the end of input incorrectly used server encoding's max character length, instead of the client's. Usually the server and client encodings are the same when we're not performing encoding conversion, but SQL_ASCII is an exception. In the passing, also fix some outdated comments that still talked about the old COPY protocol. It was removed in v14. Per bug #17501 from Vitaly Voronov. Backpatch to v14 where this was introduced. Discussion: https://www.postgresql.org/message-id/17501-128b1dd039362ae6@postgresql.org 29 May 2022, 20:54:25 UTC
f6b6a8f Tom Lane 29 May 2022, 17:25:21 UTC Doc: fix missing/bogus documentation of range_intersect_agg(). The form taking anymultirange had not been documented. This was fixed in HEAD in b21c4cf95, but that should have been back-patched to v14 since the function was added there. Do so now. Also, the form taking anyrange was incorrectly documented as returning anymultirange, when it returns anyrange. Remove b21c4cf95 from the v15 release notes, since it no longer qualifies as new-in-v15. Noted by Shay Rojansky. Discussion: https://postgr.es/m/CADT4RqAktzP7t6SFf0Xqm9YhahzvsmxFbzXe-gFOd=+_CHm0JA@mail.gmail.com 29 May 2022, 17:25:21 UTC
cfce3be Thomas Munro 29 May 2022, 04:33:26 UTC Doc: Document pg_stat_recovery_prefetch.stats_reset. This column was missing from the table that describes the new view. Author: Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi.shinoda@hpe.com> Discussion: https://postgr.es/m/DM4PR84MB173401C19A0EB9B1CAAB197CEED29@DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM 29 May 2022, 05:04:46 UTC
0107855 Andres Freund 28 May 2022, 20:08:19 UTC Align stats_fetch_consistency definition with guc.c default. Somewhat embarrassing oversight in 98f897339b0. Does not have a functional impact, but is unnecessarily confusing. Reported-By: Michael Paquier <michael@paquier.xyz> Discussion: https://postgr.es/m/Yo2351qVYqd/bJws@paquier.xyz 28 May 2022, 20:11:59 UTC
b452900 Michael Paquier 28 May 2022, 06:02:08 UTC Revert "Add single-item cache when looking at topmost XID of a subtrans XID" This reverts commit 06f5295 as per issues with this approach, both in terms of efficiency impact and stability. First, contrary to the single-item cache for transaction IDs in transam.c, the cache may finish by not be hit for a long time, and without an invalidation mechanism to clear it, it would cause inconsistent results on wraparound for example. Second, the use of SubTransGetTopmostTransaction() for the caching has a limited impact on performance. SubTransGetParent() could have more impact, though the benchmarking of the single-item approach still needs to be proved, particularly under the conditions where SLRU lookups are stressed in parallel with overflowed snapshots (aka more than 64 subxids generated, for example). After discussion with Andres Freund. Discussion: https://postgr.es/m/20220524235250.gtt3uu5zktfkr4hv@alap3.anarazel.de 28 May 2022, 06:02:08 UTC
f1431f3 Michael Paquier 28 May 2022, 03:12:40 UTC Handle NULL for short descriptions of custom GUC variables If a short description is specified as NULL in one of the various DefineCustomXXXVariable() functions available to external modules to define a custom parameter, SHOW ALL would crash. This change teaches SHOW ALL to properly handle NULL short descriptions, as well as any code paths that manipulate it, to gain in flexibility. Note that help_config.c was already able to do that, when describing a set of GUCs for postgres --describe-config. Author: Steve Chavez Reviewed by: Nathan Bossart, Andres Freund, Michael Paquier, Tom Lane Discussion: https://postgr.es/m/CAGRrpzY6hO-Kmykna_XvsTv8P2DshGiU6G3j8yGao4mk0CqjHA%40mail.gmail.com Backpatch-through: 10 28 May 2022, 03:12:40 UTC
3e9abd2 David Rowley 26 May 2022, 22:37:58 UTC Teach remove_unused_subquery_outputs about window run conditions 9d9c02ccd added code to allow the executor to take shortcuts when quals on monotonic window functions guaranteed that once the qual became false it could never become true again. When possible, baserestrictinfo quals are converted to become these quals, which we call run conditions. Unfortunately, in 9d9c02ccd, I forgot to update remove_unused_subquery_outputs to teach it about these run conditions. This could cause a WindowFunc column which was unused in the target list but referenced by an upper-level WHERE clause to be removed from the subquery when the qual in the WHERE clause was converted into a window run condition. Because of this, the entire WindowClause would be removed from the query resulting in additional rows making it into the resultset when they should have been filtered out by the WHERE clause. Here we fix this by recording which target list items in the subquery have run conditions. That gets passed along to remove_unused_subquery_outputs to tell it not to remove these items from the target list. Bug: #17495 Reported-by: Jeremy Evans Reviewed-by: Richard Guo Discussion: https://postgr.es/m/17495-7ffe2fa0b261b9fa@postgresql.org 26 May 2022, 22:37:58 UTC
2b65de7 Tom Lane 26 May 2022, 18:14:05 UTC Remove misguided SSL key file ownership check in libpq. Commits a59c79564 et al. tried to sync libpq's SSL key file permissions checks with what we've used for years in the backend. We did not intend to create any new failure cases, but it turns out we did: restricting the key file's ownership breaks cases where the client is allowed to read a key file despite not having the identical UID. In particular a client running as root used to be able to read someone else's key file; and having seen that I suspect that there are other, less-dubious use cases that this restriction breaks on some platforms. We don't really need an ownership check, since if we can read the key file despite its having restricted permissions, it must have the right ownership --- under normal conditions anyway, and the point of this patch is that any additional corner cases where that works should be deemed allowable, as they have been historically. Hence, just drop the ownership check, and rearrange the permissions check to get rid of its faulty assumption that geteuid() can't be zero. (Note that the comparable backend-side code doesn't have to cater for geteuid() == 0, since the server rejects that very early on.) This does have the end result that the permissions safety check used for a root user's private key file is weaker than that used for anyone else's. While odd, root really ought to know what she's doing with file permissions, so I think this is acceptable. Per report from Yogendra Suralkar. Like the previous patch, back-patch to all supported branches. Discussion: https://postgr.es/m/MW3PR15MB3931DF96896DC36D21AFD47CA3D39@MW3PR15MB3931.namprd15.prod.outlook.com 26 May 2022, 18:14:05 UTC
ce21a36 Robert Haas 26 May 2022, 16:54:33 UTC In CREATE FOREIGN TABLE syntax synopsis, fix partitioning stuff. Foreign tables can be partitioned, but previous documentation commits left the syntax synopsis both incomplete and incorrect. Justin Pryzby and Amit Langote Discussion: http://postgr.es/m/20220521130922.GX19626@telsasoft.com 26 May 2022, 16:54:33 UTC
6217053 Tom Lane 26 May 2022, 16:25:10 UTC Avoid ERRCODE_INTERNAL_ERROR in oracle_compat.c functions. repeat() checked for integer overflow during its calculation of the required output space, but it just passed the resulting integer to palloc(). This meant that result sizes between 1GB and 2GB led to ERRCODE_INTERNAL_ERROR, "invalid memory alloc request size" rather than ERRCODE_PROGRAM_LIMIT_EXCEEDED, "requested length too large". That seems like a bit of a wart, so add an explicit AllocSizeIsValid check to make these error cases uniform. Do likewise in the sibling functions lpad() etc. While we're here, also modernize their overflow checks to use pg_mul_s32_overflow() etc instead of expensive divisions. Per complaint from Japin Li. This is basically cosmetic, so I don't feel a need to back-patch. Discussion: https://postgr.es/m/ME3P282MB16676ED32167189CB0462173B6D69@ME3P282MB1667.AUSP282.PROD.OUTLOOK.COM 26 May 2022, 16:25:10 UTC
de89d87 Bruce Momjian 26 May 2022, 02:19:20 UTC relnotes: update ordered partition scan item Reported-by: Amit Langote Discussion: https://postgr.es/m/CA+HiwqFMmOK9cjrqxJeY1HKKbgMup0HcZ+Co7JuzJG_8ZypceA@mail.gmail.com 26 May 2022, 02:19:20 UTC
0dc379d Michael Paquier 25 May 2022, 05:21:05 UTC Add tab completion for table_rewrite's CREATE EVENT TRIGGER in psql Author: Hou Zhijie Discussion: https://postgr.es/m/OS0PR01MB5716DEFF787B925C4778228C94D69@OS0PR01MB5716.jpnprd01.prod.outlook.com 25 May 2022, 05:21:05 UTC
back to top