Skip to main content

Browse the archive

https://github.com/postgres/postgres
02 May 2024, 11:03:54 UTC
sort by:
Revision Author Date Message Commit Date
d94dadc Tom Lane 28 August 2023, 20:26:56 UTC Stamp 16rc1. 28 August 2023, 20:26:56 UTC
66ed5a2 Peter Eisentraut 28 August 2023, 07:23:57 UTC Translation updates Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: a58360c10bd5a0f0153fcf75d0b5291ac1acecb0 28 August 2023, 07:23:57 UTC
ef0e7db Peter Eisentraut 27 August 2023, 18:30:53 UTC Update list of acknowledgments in release notes current through a842ba407c 27 August 2023, 18:30:53 UTC
60d7d50 Peter Eisentraut 27 August 2023, 18:29:05 UTC Remove incorrect name from release notes This name was incorrect in the underlying commit message. (The correct name is already listed.) Reported-by: Denis Laxalde <denis.laxalde@dalibo.com> 27 August 2023, 18:29:05 UTC
8d70eb7 Peter Eisentraut 27 August 2023, 18:27:32 UTC Remove incorrect/duplicate name from list of acknowledgments Reported-by: Vik Fearing <vik@postgresfriends.org> 27 August 2023, 18:27:32 UTC
a842ba4 Bruce Momjian 25 August 2023, 01:44:31 UTC doc: PG 16 relnotes: fix initdb encoding/locale item Reported-by: Jeff Davis Discussion: https://postgr.es/m/c5369641862637c71a6c1c440ac7f122068ca4e7.camel@j-davis.com Backpatch-through: 16 only 25 August 2023, 01:44:31 UTC
2e7d15a Nathan Bossart 24 August 2023, 17:13:31 UTC pg_upgrade: Bump MESSAGE_WIDTH. Commit 7b378237aa added a status message to pg_upgrade that is 60 characters wide. Since the MESSAGE_WIDTH macro is currently set to 60, there is no space between this new status message and the "ok" or "failed" indicator appended when the step completes. To fix this problem, this commit increases the value of MESSAGE_WIDTH to 62. Suggested-by: Bharath Rupireddy Reviewed-by: Peter Eisentraut Discussion: https://postgr.es/m/CALj2ACVVvk1cYLtWVxHv%3DZ1Ubq%3DUES9fhKbUU4c9k4W%2BfEDnbw%40mail.gmail.com Backpatch-through: 16 24 August 2023, 17:13:45 UTC
ba0d737 Tom Lane 24 August 2023, 16:02:40 UTC Avoid unnecessary plancache revalidation of utility statements. Revalidation of a plancache entry (after a cache invalidation event) requires acquiring a snapshot. Normally that is harmless, but not if the cached statement is one that needs to run without acquiring a snapshot. We were already aware of that for TransactionStmts, but for some reason hadn't extrapolated to the other statements that PlannedStmtRequiresSnapshot() knows mustn't set a snapshot. This can lead to unexpected failures of commands such as SET TRANSACTION ISOLATION LEVEL. We can fix it in the same way, by excluding those command types from revalidation. However, we can do even better than that: there is no need to revalidate for any statement type for which parse analysis, rewrite, and plan steps do nothing interesting, which is nearly all utility commands. To mechanize this, invent a parser function stmt_requires_parse_analysis() that tells whether parse analysis does anything beyond wrapping a CMD_UTILITY Query around the raw parse tree. If that's what it does, then rewrite and plan will just skip the Query, so that it is not possible for the same raw parse tree to produce a different plan tree after cache invalidation. stmt_requires_parse_analysis() is basically equivalent to the existing function analyze_requires_snapshot(), except that for obscure reasons that function omits ReturnStmt and CallStmt. It is unclear whether those were oversights or intentional. I have not been able to demonstrate a bug from not acquiring a snapshot while analyzing these commands, but at best it seems mighty fragile. It seems safer to acquire a snapshot for parse analysis of these commands too, which allows making stmt_requires_parse_analysis and analyze_requires_snapshot equivalent. In passing this fixes a second bug, which is that ResetPlanCache would exclude ReturnStmts and CallStmts from revalidation. That's surely *not* safe, since they contain parsable expressions. Per bug #18059 from Pavel Kulakov. Back-patch to all supported branches. Discussion: https://postgr.es/m/18059-79c692f036b25346@postgresql.org 24 August 2023, 16:02:40 UTC
ce18252 Peter Eisentraut 24 August 2023, 12:22:02 UTC Fix lack of message pluralization 24 August 2023, 12:22:02 UTC
4cdcff4 Peter Eisentraut 24 August 2023, 11:59:40 UTC Update DECLARE_INDEX documentation Update source code comment changes belonging to the changes in 6a6389a08b. Discussion: https://www.postgresql.org/message-id/flat/75ae5875-3abc-dafc-8aec-73247ed41cde@eisentraut.org 24 August 2023, 12:00:36 UTC
155c814 Peter Eisentraut 22 August 2023, 12:12:45 UTC Rename hook functions for debug_io_direct to match variable name. Commit 319bae9a renamed the GUC. Rename the check and assign functions to match, and alphabetize. Back-patch to 16. Author: Peter Eisentraut <peter@eisentraut.org> Discussion: https://postgr.es/m/2769341e-fa28-c2ee-3e4b-53fdcaaf2271%40eisentraut.org 24 August 2023, 10:27:53 UTC
13e2665 Amit Kapila 24 August 2023, 09:21:57 UTC Fix the error message when failing to restore the snapshot. The SnapBuildRestoreContents() used a const value in the error message to indicate the size in bytes it was expecting to read from the serialized snapshot file. Fix it by reporting the size that was actually passed. Author: Hou Zhijie Reviewed-by: Amit Kapila Backpatch-through: 16 Discussion: http://postgr.es/m/OS0PR01MB5716D408364F7DF32221C08D941FA@OS0PR01MB5716.jpnprd01.prod.outlook.com 24 August 2023, 09:21:57 UTC
8179d1b Peter Eisentraut 24 August 2023, 08:24:38 UTC Fix translation markers Conditionals cannot be inside gettext trigger functions, they must be applied outside. 24 August 2023, 08:24:38 UTC
8fa09a1 Peter Eisentraut 24 August 2023, 06:23:43 UTC pg_upgrade: Improve one log message The parenthesized plural is unnecessary here and inconsistent with nearby similar messages. 24 August 2023, 06:23:43 UTC
7d8e703 Bruce Momjian 24 August 2023, 01:33:03 UTC do: PG 16 relnotes: clarify last seq/index view names Backpatch-through: 16 only 24 August 2023, 01:33:03 UTC
5a16984 David Rowley 23 August 2023, 22:33:48 UTC Meson: check for pg_config_paths.h left over from make The meson build scripts attempt to find files left over from configure and fail, mentioning that "make maintainer-clean" should be run to remove these. This seems to have been done for files generated from configure. pg_config_paths.h is generated during the actual make build, so seems to have been missed. This would result in compilation using the wrong pg_config_paths.h file. Here we just add this file to generated_sources_ac so that meson errors out if pg_config_paths.h exists. Likely this wasn't noticed before because make maintainer-clean will remove pg_config_paths.h, however, people using the MSVC build scripts are more likely to run into issues and they have to manually remove these files and pg_config_paths.h wasn't listed as a conflicting file to remove in the meson log. Backpatch-through: 16, where meson support was added Discussion: https://postgr.es/m/CAApHDvqjYOxZfmLKAOWKFEE7LOr9_E6UA6YNmx9r8nxStcS3gg@mail.gmail.com 23 August 2023, 22:33:48 UTC
e8a8cd0 Andres Freund 23 August 2023, 22:15:28 UTC ci: Make compute resources for CI configurable See prior commit for an explanation for the goal of the change and why it had to be split into two commits. Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com> Discussion: https://postgr.es/m/20230808021541.7lbzdefvma7qmn3w@awork3.anarazel.de Backpatch: 15-, where CI support was added 23 August 2023, 22:15:28 UTC
9ed46c7 Andres Freund 23 August 2023, 22:15:28 UTC ci: Prepare to make compute resources for CI configurable cirrus-ci will soon restrict the amount of free resources every user gets (as have many other CI providers). For most users of CI that should not be an issue. But e.g. for cfbot it will be an issue. To allow configuring different resources on a per-repository basis, introduce infrastructure for overriding the task execution environment. Unfortunately this is not entirely trivial, as yaml anchors have to be defined before their use, and cirrus-ci only allows injecting additional contents at the end of .cirrus.yml. To deal with that, move the definition of the CI tasks to .cirrus.tasks.yml. The main .cirrus.yml is loaded first, then, if defined, the file referenced by the REPO_CI_CONFIG_GIT_URL variable, will be added, followed by the contents of .cirrus.tasks.yml. That allows REPO_CI_CONFIG_GIT_URL to override the yaml anchors defined in .cirrus.yml. Unfortunately git's default merge / rebase strategy does not handle copied files, just renamed ones. To avoid painful rebasing over this change, this commit just renames .cirrus.yml to .cirrus.tasks.yml, without adding a new .cirrus.yml. That's done in the followup commit, which moves the relevant portion of .cirrus.tasks.yml to .cirrus.yml. Until that is done, REPO_CI_CONFIG_GIT_URL does not fully work. The subsequent commit adds documentation for how to configure custom compute resources to src/tools/ci/README Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Reviewed-by: Nazir Bilal Yavuz <byavuz81@gmail.com> Discussion: https://postgr.es/m/20230808021541.7lbzdefvma7qmn3w@awork3.anarazel.de Backpatch: 15-, where CI support was added 23 August 2023, 22:15:28 UTC
f518c90 Andres Freund 23 August 2023, 19:29:50 UTC ci: Use VMs for SanityCheck and CompilerWarnings The main reason for this change is to reduce different ways of executing tasks, making it easier to use custom compute resources for cfbot. A secondary benefit is that the tasks seem slightly faster this way, apparently the increased startup overhead is outweighed by reduced runtime overhead. Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://postgr.es/m/20230808021541.7lbzdefvma7qmn3w@awork3.anarazel.de Backpatch: 15-, where CI support was added 23 August 2023, 19:29:50 UTC
cad461b Andres Freund 23 August 2023, 19:27:40 UTC ci: Move execution method of tasks into yaml templates This is done in preparation for making the compute resources for CI configurable. It also looks cleaner. Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://postgr.es/m/20230808021541.7lbzdefvma7qmn3w@awork3.anarazel.de Backpatch: 15-, where CI support was added 23 August 2023, 19:27:40 UTC
5581a9a Andres Freund 23 August 2023, 19:27:29 UTC ci: Don't specify amount of memory The number of CPUs is the cost-determining factor. Most instance types that run tests have more memory/core than what we specified, there's no real benefit in wasting that. Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://postgr.es/m/20230808021541.7lbzdefvma7qmn3w@awork3.anarazel.de Backpatch: 15-, where CI support was added 23 August 2023, 19:27:29 UTC
c3b874c Heikki Linnakangas 23 August 2023, 15:08:40 UTC Fix _bt_allequalimage() call within critical section. _bt_allequalimage() does complicated things, so it's not OK to call it in a critical section. Per buildfarm failure on 'prion', which uses -DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE options. Discussion: https://www.postgresql.org/message-id/6e5bbc08-cdfc-b2b3-9e23-1a914b9850a9@iki.fi Backpatch-through: 16, like commit ccadf73163 that introduced this 23 August 2023, 15:11:51 UTC
6bc1fd4 Heikki Linnakangas 23 August 2023, 14:21:31 UTC Use the buffer cache when initializing an unlogged index. Some of the ambuildempty functions used smgrwrite() directly, followed by smgrimmedsync(). A few small problems with that: Firstly, one is supposed to use smgrextend() when extending a relation, not smgrwrite(). It doesn't make much difference in production builds. smgrextend() updates the relation size cache, so you miss that, but that's harmless because we never use the cached relation size of an init fork. But if you compile with CHECK_WRITE_VS_EXTEND, you get an assertion failure. Secondly, the smgrwrite() calls were performed before WAL-logging, so the page image written to disk had 0/0 as the LSN, not the LSN of the WAL record. That's also harmless in practice, but seems sloppy. Thirdly, it's better to use the buffer cache, because then you don't need to smgrimmedsync() the relation to disk, which adds latency. Bypassing the cache makes sense for bulk operations like index creation, but not when you're just initializing an empty index. Creation of unlogged tables is hardly performance bottleneck in any real world applications, but nevertheless. Backpatch to v16, but no further. These issues should be harmless in practice, so better to not rock the boat in older branches. Reviewed-by: Robert Haas Discussion: https://www.postgresql.org/message-id/6e5bbc08-cdfc-b2b3-9e23-1a914b9850a9@iki.fi 23 August 2023, 14:23:18 UTC
5fd424c Daniel Gustafsson 23 August 2023, 12:13:07 UTC doc: Replace list of drivers and PLs with wiki link The list of external language drivers and procedural languages was never complete or exhaustive, and rather than attempting to manage it the content has migrated to the wiki. This replaces the tables altogether with links to the wiki as we regularly get requests for adding various projects, which we reject without any clear policy for why or how the content should be managed. The threads linked to below are the most recent discussions about this, the archives contain many more. Backpatch to all supported branches since the list on the wiki applies to all branches. Author: Jonathan Katz <jkatz@postgresql.org> Discussion: https://postgr.es/m/169165415312.635.10247434927885764880@wrigleys.postgresql.org Discussion: https://postgr.es/m/169177958824.635.11087800083040275266@wrigleys.postgresql.org Backpatch-through: v11 23 August 2023, 12:13:07 UTC
103df20 Peter Eisentraut 23 August 2023, 09:23:42 UTC doc: Add more ICU rules examples In particular, add an example EBCDIC collation. Author: Daniel Verite <daniel@manitou-mail.org> Discussion: https://www.postgresql.org/message-id/flat/35cc1684-e516-4a01-a256-351632d47066@manitou-mail.org 23 August 2023, 09:24:43 UTC
0b9127d Peter Eisentraut 23 August 2023, 06:25:56 UTC doc: Improve ICU external link It previously pointed to the collation API documentation, which our users don't need, but the containing chapter seems useful. 23 August 2023, 06:26:53 UTC
6f168e0 Peter Eisentraut 23 August 2023, 06:12:50 UTC Improve vertical spacing of documentation markup 23 August 2023, 06:13:22 UTC
f58af9f Thomas Munro 23 August 2023, 00:10:18 UTC ExtendBufferedWhat -> BufferManagerRelation. Commit 31966b15 invented a way for functions dealing with relation extension to accept a Relation in online code and an SMgrRelation in recovery code. It seems highly likely that future bufmgr.c interfaces will face the same problem, and need to do something similar. Generalize the names so that each interface doesn't have to re-invent the wheel. Back-patch to 16. Since extension AM authors might start using the constructor macros once 16 ships, we agreed to do the rename in 16 rather than waiting for 17. Reviewed-by: Peter Geoghegan <pg@bowt.ie> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CA%2BhUKG%2B6tLD2BhpRWycEoti6LVLyQq457UL4ticP5xd8LqHySA%40mail.gmail.com 23 August 2023, 00:33:24 UTC
d8cd49e Bruce Momjian 22 August 2023, 23:37:26 UTC doc: PG 16 relnotes: properly indent and word-wrap text Backpatch-through: 16 only 22 August 2023, 23:37:26 UTC
501704e Jeff Davis 22 August 2023, 18:21:36 UTC Fix pg_dump assertion failure when dumping pg_catalog. Commit 396d348b04 did not account for the default collation. Also, use pg_log_warning() instead of Assert(). Discussion: https://postgr.es/m/ce071503fee88334aa70f360e6e4ea14d48305ee.camel%40j-davis.com Reviewed-by: Michael Paquier Backpatch-through: 15 22 August 2023, 19:49:40 UTC
f938acd Andrew Dunstan 22 August 2023, 15:57:08 UTC Cache by-reference missing values in a long lived context Attribute missing values might be needed past the lifetime of the tuple descriptors from which they are extracted. To avoid possibly using pointers for by-reference values which might thus be left dangling, we cache a datumCopy'd version of the datum in the TopMemoryContext. Since we first search for the value this only needs to be done once per session for any such value. Original complaint from Tom Lane, idea for mitigation by Andrew Dunstan, tweaked by Tom Lane. Backpatch to version 11 where missing values were introduced. Discussion: https://postgr.es/m/1306569.1687978174@sss.pgh.pa.us 22 August 2023, 19:18:19 UTC
e9f5354 Bruce Momjian 22 August 2023, 19:15:24 UTC doc: PG 16 relnotes: separate out psql \drg item Reported-by: Pavel Luzanov Discussion: https://postgr.es/m/29b97504-80a3-fdcc-538e-cadde3d8ecd5@postgrespro.ru Backpatch-through: 16 only 22 August 2023, 19:15:24 UTC
8c76a55 Peter Eisentraut 22 August 2023, 08:54:16 UTC Add list of acknowledgments to release notes This contains all individuals mentioned in the commit messages during PostgreSQL 16 development. current through REL_16_BETA3 22 August 2023, 09:20:39 UTC
7fb906d Bruce Momjian 21 August 2023, 22:55:41 UTC doc: PG 16 relnotes: adjust RANGE/ROWS window item Reported-by: Erwin Brandstetter Discussion: https://postgr.es/m/CAGHENJ5Cj3wBH07YM5Lw2h5q8s65cNg_NEdkkWvmRo+vOormWw@mail.gmail.com Backpatch-through: 16 only 21 August 2023, 22:55:41 UTC
00be0bc Bruce Momjian 21 August 2023, 21:54:29 UTC doc: PG 16 relnotes: move role INHERIT item and clarify it Also split out new role ADMIN syntax entry. Reported-by: Pavel Luzanov Discussion: https://postgr.es/m/0ebcc8ea-7f5a-d014-d53f-e078622be35d@aklaver.com Backpatch-through: 16 only 21 August 2023, 21:54:29 UTC
d6af450 Michael Paquier 21 August 2023, 04:33:04 UTC Fix pg_stat_reset_single_table_counters() for shared relations This commit fixes the function of $subject for shared relations. This feature has been added by e042678. Unfortunately, this new behavior got removed by 5891c7a when moving statistics to shared memory. Reported-by: Mitsuru Hinata Author: Masahiro Ikeda Reviewed-by: Kyotaro Horiguchi, Masahiko Sawada Discussion: https://postgr.es/m/7cc69f863d9b1bc677544e3accd0e4b4@oss.nttdata.com Backpatch-through: 15 21 August 2023, 04:33:04 UTC
dd2a731 Andres Freund 19 August 2023, 19:40:45 UTC ci: macos: use cached macports install A significant chunk of the time on the macos CI task is spent installing packages using homebrew. The downloads of the packages are cached, but the installation needs to happen every time. We can't cache the whole homebrew installation, because it is too large due to pre-installed packages. Speed this up by installing packages using macports and caching the installation as .dmg. That's a lot faster than unpacking a tarball. In addition, don't install llvm - it wasn't enabled when building, so it's just a waste of time/space. This substantially speeds up the mac CI time, both in the cold cache and in the warm cache case (the latter from ~1m20s to ~5s). It doesn't seem great to have diverging sources of packages for CI between branches, so backpatch to 15 (where CI was added). Discussion: https://postgr.es/m/20230805202539.r3umyamsnctysdc7@awork3.anarazel.de Backpatch: 15-, where CI was added 19 August 2023, 21:38:56 UTC
dcfc49c Peter Eisentraut 18 August 2023, 05:41:14 UTC Remove dubious warning message from SQL/JSON functions There was a warning that FORMAT JSON has no effect on json/jsonb types, which is true, but it's not clear why we should issue a warning about it. The SQL standard does not say anything about this, which should generally govern the behavior here. So remove it. Discussion: https://www.postgresql.org/message-id/flat/dfec2cae-d17e-c508-6d16-c2dba82db486%40eisentraut.org 18 August 2023, 05:43:52 UTC
6337e99 Thomas Munro 17 August 2023, 03:45:13 UTC Invalidate smgr_targblock in smgrrelease(). In rare circumstances involving relfilenode reuse, it might have been possible for smgr_targblock to finish up pointing past the end. Oversight in b74e94dc. Back-patch to 15. Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Discussion: https://postgr.es/m/CA%2BhUKGJ8NTvqLHz6dqbQnt2c8XCki4r2QvXjBQcXpVwxTY_pvA%40mail.gmail.com 17 August 2023, 03:54:04 UTC
11f4935 Bruce Momjian 17 August 2023, 02:22:12 UTC doc: PG 16 relnotes, add links to doc sections Backpatch-through: 16 only 17 August 2023, 02:22:12 UTC
6b86a3e Bruce Momjian 16 August 2023, 18:34:49 UTC doc: PG 16 relnotes, initial markup Still need to add links to doc sections. Backpatch-through: 16 only 16 August 2023, 18:34:49 UTC
c672262 Peter Eisentraut 16 August 2023, 14:17:00 UTC Unify some error messages We had essentially the same error in several different wordings. Unify that. 16 August 2023, 14:18:49 UTC
842b659 Peter Eisentraut 16 August 2023, 13:09:50 UTC Improved CREATE SUBSCRIPTION message for clarity Discussion: https://www.postgresql.org/message-id/CAHut+PtfzQ7JRkb0-Y_UejAxaLQ17-bGMvV4MJJHcPoP3ML2bg@mail.gmail.com 16 August 2023, 13:09:50 UTC
c5c8bd2 Bruce Momjian 15 August 2023, 13:15:21 UTC doc: PG 16 relnotes, update "current as of" date Backpatch-through: 16 only 15 August 2023, 13:15:21 UTC
acc5c4f Thomas Munro 14 August 2023, 22:20:11 UTC De-pessimize ConditionVariableCancelSleep(). Commit b91dd9de was concerned with a theoretical problem with our non-atomic condition variable operations. If you stop sleeping, and then cancel the sleep in a separate step, you might be signaled in between, and that could be lost. That doesn't matter for callers of ConditionVariableBroadcast(), but callers of ConditionVariableSignal() might be upset if a signal went missing like this. Commit bc971f4025c interacted badly with that logic, because it doesn't use ConditionVariableSleep(), which would normally put us back in the wait list. ConditionVariableCancelSleep() would be confused and think we'd received an extra signal, and try to forward it to another backend, resulting in wakeup storms. New idea: ConditionVariableCancelSleep() can just return true if we've been signaled. Hypothetical users of ConditionVariableSignal() would then still have a way to deal with rare lost signals if they are concerned about that problem. Back-patch to 16, where bc971f4025c arrived. Reported-by: Tomas Vondra <tomas.vondra@enterprisedb.com> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/2840876b-4cfe-240f-0a7e-29ffd66711e7%40enterprisedb.com 14 August 2023, 22:33:55 UTC
03fb43f Bruce Momjian 14 August 2023, 21:28:39 UTC doc: PG 16 relnotes: udpate for commits since branching Backpatch-through: 16 only 14 August 2023, 21:28:39 UTC
d37ab37 Andres Freund 14 August 2023, 16:54:03 UTC hio: Take number of prior relation extensions into account The new relation extension logic, introduced in 00d1e02be24, could lead to slowdowns in some scenarios. E.g., when loading narrow rows into a table using COPY, the caller of RelationGetBufferForTuple() will only request a small number of pages. Without concurrency, we just extended using pwritev() in that case. However, if there is *some* concurrency, we switched between extending by a small number of pages and a larger number of pages, depending on the number of waiters for the relation extension logic. However, some filesystems, XFS in particular, do not perform well when switching between extending files using fallocate() and pwritev(). To avoid that issue, remember the number of prior relation extensions in BulkInsertState and extend more aggressively if there were prior relation extensions. That not just avoids the aforementioned slowdown, but also leads to noticeable performance gains in other situations, primarily due to extending more aggressively when there is no concurrency. I should have done it this way from the get go. Reported-by: Masahiko Sawada <sawada.mshk@gmail.com> Author: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CAD21AoDvDmUQeJtZrau1ovnT_smN940=Kp6mszNGK3bq9yRN6g@mail.gmail.com Backpatch: 16-, where the new relation extension code was added 14 August 2023, 16:54:38 UTC
2243ef8 Andres Freund 12 August 2023, 20:09:45 UTC ci: macos: Remove use of -Dsegsize_blocks=6 The option causes a measurable slowdown. Macos is, by far, the most expensive platform for CI, therefore it doesn't make sense to run such a test there. d3b111e3205 used a small segment size for two tasks, one with autoconf, one with meson. In hindsight that is a bit overkill, it's unlikely that the option would silently break. Thus don't move the -Dsegsize_blocks=6, just remove it. I did however change the autoconf test to use 6 instead of 8 blocks, as long as we allow it, a non-power-of-two test seems like a good idea. While at it, add a comment explaining why we use a small segment size for CI. Author: Andres Freund <andres@anarazel.de> Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Discussion: https://postgr.es/m/20230808021541.7lbzdefvma7qmn3w@awork3.anarazel.de Backpatch: 16-, where d3b111e3205 introduced the use of -Dsegsize_blocks=6 12 August 2023, 22:08:08 UTC
4bec616 Andres Freund 12 August 2023, 20:06:04 UTC ci: macos: Remove use of -DRANDOMIZE_ALLOCATED_MEMORY RANDOMIZE_ALLOCATED_MEMORY causes a measurable slowdown. Macos is, by far, the most expensive platform for CI, therefore it doesn't make sense to run such a test there. Ubsan and asan on linux should detect most of the the cases of uninitialized memory, so it doesn't really seem worth using -DRANDOMIZE_ALLOCATED_MEMORY in another instance type. Author: Andres Freund <andres@anarazel.de> Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Discussion: https://postgr.es/m/20230808021541.7lbzdefvma7qmn3w@awork3.anarazel.de Backpatch: 16-, where 89d16b635 added the use of -DRANDOMIZE_ALLOCATED_MEMORY 12 August 2023, 22:08:07 UTC
7823a29 Noah Misch 12 August 2023, 21:37:05 UTC Fix off-by-one in XLogRecordMaxSize check. pg_logical_emit_message(false, '_', repeat('x', 1069547465)) failed with self-contradictory message "WAL record would be 1069547520 bytes (of maximum 1069547520 bytes)". There's no particular benefit from allowing or denying one byte in either direction; XLogRecordMaxSize could rise a few megabytes without trouble. Hence, this is just for cleanliness. Back-patch to v16, where this check first appeared. 12 August 2023, 21:37:11 UTC
7bed93a Jeff Davis 10 August 2023, 17:16:59 UTC Remove test from commit fa2e874946. The fix itself is fine, but the test revealed other problems related to parallel query that are not easily fixable. Remove the test for now to fix the buildfarm. Discussion: https://postgr.es/m/88825.1691665432@sss.pgh.pa.us Backpatch-through: 11 10 August 2023, 17:24:58 UTC
1b594a3 Alvaro Herrera 10 August 2023, 10:04:07 UTC Document RelationGetIndexAttrBitmap better Commit 19d8e2308bc5 changed the list of set-of-columns that can be returned by RelationGetIndexAttrBitmap, but didn't update its "documentation". That was pretty hard to read already, so rewrite to make it more comprehensible, adding the missing values while at it. Backpatch to 16, like that commit. Discussion: https://postgr.es/m/20230809091155.7c7f3gttjk3dj4ze@alvherre.pgsql Reviewed-by: Tomas Vondra <tomas.vondra@enterprisedb.com> 10 August 2023, 10:04:07 UTC
c8c033f Bruce Momjian 10 August 2023, 02:09:17 UTC doc: PG 16 relnotes, mark current as of 2023-08-09 Backpatch-through: 16 only 10 August 2023, 02:09:17 UTC
fc3e212 Bruce Momjian 10 August 2023, 00:48:31 UTC doc: PG 16 relnotes, move createuser and SCM items Reported-by: Noah Misch Discussion: https://postgr.es/m/20230805230847.GA1370050@rfd.leadboat.com Backpatch-through: 16 only 10 August 2023, 00:48:31 UTC
0752461 Bruce Momjian 10 August 2023, 00:37:41 UTC doc: PG 16 relnotes, small wording improvement Backpatch-through: 16 only 10 August 2023, 00:37:41 UTC
6e1d1c5 Bruce Momjian 09 August 2023, 22:01:50 UTC doc: PG 16 relnotes, merge and adjust CREATEROLE items Reported-by: Noah Misch Discussion: https://postgr.es/m/20230805230847.GA1370050@rfd.leadboat.com Backpatch-through: 16 only 09 August 2023, 22:01:50 UTC
89cadf3 Bruce Momjian 09 August 2023, 21:47:03 UTC doc: PG 16 relnotes, add Windows 10 huge pages fix Reported-by: Michael Paquier Discussion: https://postgr.es/m/ZL0M28/L+grYR8o7@paquier.xyz Backpatch-through: 16 only 09 August 2023, 21:47:03 UTC
0d56c32 Jeff Davis 07 August 2023, 22:13:06 UTC Recalculate search_path after ALTER ROLE. Renaming a role can affect the meaning of the special string $user, so must cause search_path to be recalculated. Discussion: https://postgr.es/m/186761d32c0255debbdf50b6310b581b9c973e6c.camel@j-davis.com Reviewed-by: Nathan Bossart, Michael Paquier Backpatch-through: 11 09 August 2023, 20:09:01 UTC
e90308a Bruce Momjian 09 August 2023, 17:56:26 UTC doc: PG 16 relnotes, fix various typos Reported-by: Erik Rijkers Discussion: https://postgr.es/m/9c83328b-c0ff-070f-f2be-c3dce484e182@xs4all.nl Backpatch-through: 16 only 09 August 2023, 17:56:26 UTC
98cb73f Bruce Momjian 09 August 2023, 17:23:39 UTC doc: PG 16 relnotes, adjust \ef+ body comment to mention \sf Reported-by: Laurenz Albe Discussion: https://postgr.es/m/99d731a543501eb31bf7b8db43d231a037d7cc80.camel@cybertec.at Backpatch-through: 16 only 09 August 2023, 17:23:39 UTC
8641515 Bruce Momjian 09 August 2023, 15:16:26 UTC doc: PG 16 relnotes, remove MAINTAIN item Feature was removed by commit 957445996f. Discussion: 957445996f Backpatch-through: 16 09 August 2023, 15:16:26 UTC
0dd5545 Tom Lane 07 August 2023, 20:05:20 UTC Stamp 16beta3. 07 August 2023, 20:05:20 UTC
f535110 Noah Misch 07 August 2023, 13:05:56 UTC Reject substituting extension schemas or owners matching ["$'\]. Substituting such values in extension scripts facilitated SQL injection when @extowner@, @extschema@, or @extschema:...@ appeared inside a quoting construct (dollar quoting, '', or ""). No bundled extension was vulnerable. Vulnerable uses do appear in a documentation example and in non-bundled extensions. Hence, the attack prerequisite was an administrator having installed files of a vulnerable, trusted, non-bundled extension. Subject to that prerequisite, this enabled an attacker having database-level CREATE privilege to execute arbitrary code as the bootstrap superuser. By blocking this attack in the core server, there's no need to modify individual extensions. Back-patch to v11 (all supported versions). Reported by Micah Gate, Valerie Woolard, Tim Carey-Smith, and Christoph Berg. Security: CVE-2023-39417 07 August 2023, 13:05:59 UTC
e8386b2 Peter Eisentraut 07 August 2023, 10:06:49 UTC Translation updates Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 97398d714ace69f0c919984e160f429b6fd2300e 07 August 2023, 10:39:10 UTC
ae89129 David Rowley 07 August 2023, 10:14:54 UTC Don't Memoize lateral joins with volatile join conditions The use of Memoize was already disabled in normal joins when the join conditions had volatile functions per the code in match_opclause_to_indexcol(). Ordinarily, the parameterization for the inner side of a nested loop will be an Index Scan or at least eventually lead to an index scan (perhaps nested several joins deep). However, for lateral joins, that's not the case and seq scans can be parameterized too, so we can't rely on match_opclause_to_indexcol(). Here we explicitly check the parameterization for volatile functions and don't consider the generation of a Memoize path when such functions are present. Author: Richard Guo Discussion: https://postgr.es/m/CAMbWs49nHFnHbpepLsv_yF3qkpCS4BdB-v8HoJVv8_=Oat0u_w@mail.gmail.com Backpatch-through: 14, where Memoize was introduced 07 August 2023, 10:14:54 UTC
67a007d Dean Rasheed 07 August 2023, 08:27:09 UTC Fix RLS policy usage in MERGE. If MERGE executes an UPDATE action on a table with row-level security, the code incorrectly applied the WITH CHECK clauses from the target table's INSERT policies to new rows, instead of the clauses from the table's UPDATE policies. In addition, it failed to check new rows against the target table's SELECT policies, if SELECT permissions were required (likely to always be the case). In addition, if MERGE executes a DO NOTHING action for matched rows, the code incorrectly applied the USING clauses from the target table's DELETE policies to existing target tuples. These policies were applied as checks that would throw an error, if they did not pass. Fix this, so that a MERGE UPDATE action applies the same RLS policies as a plain UPDATE query with a WHERE clause, and a DO NOTHING action does not apply any RLS checks (other than adding clauses from SELECT policies to the join). Back-patch to v15, where MERGE was introduced. Dean Rasheed, reviewed by Stephen Frost. Security: CVE-2023-39418 07 August 2023, 08:27:09 UTC
f0a3805 Etsuro Fujita 03 August 2023, 08:45:01 UTC Doc: update documentation for creating custom scan paths. Commit f49842d1e added a new callback for custom scan paths, but missed updating the documentation. Back-patch to all supported branches. Discussion: https://postgr.es/m/CAPmGK15ODkN%2B%3DhkBCufj1HBW0x5OTb65Xuy7ryXchMdiCMpx_g%40mail.gmail.com 03 August 2023, 08:45:01 UTC
c575e00 Etsuro Fujita 03 August 2023, 08:15:01 UTC Update comments on CustomPath struct. Commit e7cb7ee14 allowed custom scan providers to create CustomPath paths for join relations as well, but missed updating the comments. Back-patch to all supported branches. Discussion: https://postgr.es/m/CAPmGK15ODkN%2B%3DhkBCufj1HBW0x5OTb65Xuy7ryXchMdiCMpx_g%40mail.gmail.com 03 August 2023, 08:15:01 UTC
5c0fcef Masahiko Sawada 02 August 2023, 06:01:10 UTC Fix ReorderBufferCheckMemoryLimit() comment. Commit 7259736a6 updated the comment but it was not correct since ReorderBufferLargestStreamableTopTXN() returns only top-level transactions. Reviewed-by: Amit Kapila Discussion: https://postgr.es/m/CAD21AoA9XB7OR86BqvrCe2dMYX%2BZv3-BvVmjF%3DGY2z6jN-kqjg%40mail.gmail.com Backpatch-through: 14 02 August 2023, 06:01:10 UTC
803660e Andres Freund 01 August 2023, 18:22:03 UTC Fix pg_stat_io buffer reuse test instability The stats regression test attempts to ensure that Buffer Access Strategy "reuses" are being counted in pg_stat_io by vacuuming a table which is larger than the size of the strategy ring. However, when shared buffers are in sufficiently high demand, another backend could evict one of the blocks in the strategy ring before the first backend has a chance to reuse the buffer. The backend using the strategy would then evict another shared buffer and add that buffer to the strategy ring. This counts as an eviction and not a reuse in pg_stat_io. Count both evictions and reuses in the test to ensure it does not fail incorrectly. Reported-by: Jeff Davis <pgsql@j-davis.com>, Author: Melanie Plageman <melanieplageman@gmail.com> Reviewed-by: Alexander Lakhin <exclusion@gmail.com> Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com> Discussion: https://postgr.es/m/CAAKRu_bNG27AxG9TdPtwsL6wg8AWbVckjmTL2t1HF=miDQuNtw@mail.gmail.com 02 August 2023, 02:04:29 UTC
4e2e75c David Rowley 02 August 2023, 00:06:08 UTC Fix performance regression in pg_strtointNN_safe functions Between 6fcda9aba and 1b6f632a3, the pg_strtoint functions became quite a bit slower in v16, despite efforts in 6b423ec67 to speed these up. Since the majority of cases for these functions will only contain base-10 digits, perhaps prefixed by a '-', it makes sense to have a special case for this and just fall back on the more complex version which processes hex, octal, binary and underscores if the fast path version fails to parse the string. While we're here, update the header comments for these functions to mention that hex, octal and binary formats along with underscore separators are now supported. Author: Andres Freund, David Rowley Reported-by: Masahiko Sawada Reviewed-by: Dean Rasheed, John Naylor Discussion: https://postgr.es/m/CAD21AoDvDmUQeJtZrau1ovnT_smN940%3DKp6mszNGK3bq9yRN6g%40mail.gmail.com Backpatch-through: 16, where 6fcda9aba and 1b6f632a3 were added 02 August 2023, 00:06:08 UTC
b25acc3 David Rowley 01 August 2023, 13:40:27 UTC Fix overly strict Assert in jsonpath code This was failing for queries which try to get the .type() of a jpiLikeRegex. For example: select jsonb_path_query('["string", "string"]', '($[0] like_regex ".{7}").type()'); Reported-by: Alexander Kozhemyakin Bug: #18035 Discussion: https://postgr.es/m/18035-64af5cdcb5adf2a9@postgresql.org Backpatch-through: 12, where SQL/JSON path was added. 01 August 2023, 13:40:27 UTC
695f5de Etsuro Fujita 28 July 2023, 06:45:01 UTC Disallow replacing joins with scans in problematic cases. Commit e7cb7ee14, which introduced the infrastructure for FDWs and custom scan providers to replace joins with scans, failed to add support handling of pseudoconstant quals assigned to replaced joins in createplan.c, leading to an incorrect plan without a gating Result node when postgres_fdw replaced a join with such a qual. To fix, we could add the support by 1) modifying the ForeignPath and CustomPath structs to store the list of RestrictInfo nodes to apply to the join, as in JoinPaths, if they represent foreign and custom scans replacing a join with a scan, and by 2) modifying create_scan_plan() in createplan.c to use that list in that case, instead of the baserestrictinfo list, to get pseudoconstant quals assigned to the join; but #1 would cause an ABI break. So fix by modifying the infrastructure to just disallow replacing joins with such quals. Back-patch to all supported branches. Reported by Nishant Sharma. Patch by me, reviewed by Nishant Sharma and Richard Guo. Discussion: https://postgr.es/m/CADrsxdbcN1vejBaf8a%2BQhrZY5PXL-04mCd4GDu6qm6FigDZd6Q%40mail.gmail.com 28 July 2023, 06:45:01 UTC
de3f0e3 Tom Lane 27 July 2023, 15:56:35 UTC Eliminate fixed token-length limit in hba.c. Historically, hba.c limited tokens in the authentication configuration files (pg_hba.conf and pg_ident.conf) to less than 256 bytes. We have seen a few reports of this limit causing problems; notably, for moderately-complex LDAP configurations. Let's get rid of the fixed limit by using a StringInfo instead of a fixed-size buffer. This actually takes less code than before, since we can get rid of a nontrivial error recovery stanza. It's doubtless a hair slower, but parsing the content of the HBA files should in no way be performance-critical. Although this is a pretty straightforward patch, it doesn't seem worth the risk to back-patch given the small number of complaints to date. In released branches, we'll just raise MAX_TOKEN to ameliorate the problem. Discussion: https://postgr.es/m/1588937.1690221208@sss.pgh.pa.us 27 July 2023, 15:56:35 UTC
c1308ce David Rowley 27 July 2023, 02:48:44 UTC Fix performance problem with new COPY DEFAULT code 9f8377f7a added code to allow COPY FROM insert a column's default value when the input matches the DEFAULT string specified in the COPY command. Here we fix some inefficient code which needlessly palloc0'd an array to store if we should use the default value or input value for the given column. This array was being palloc0'd and pfree'd once per row. It's much more efficient to allocate this once and just reset the values once per row. Reported-by: Masahiko Sawada Author: Masahiko Sawada Discussion: https://postgr.es/m/CAD21AoDvDmUQeJtZrau1ovnT_smN940%3DKp6mszNGK3bq9yRN6g%40mail.gmail.com Backpatch-through: 16, where 9f8377f7a was introduced. 27 July 2023, 02:48:44 UTC
b4f14d2 Masahiko Sawada 26 July 2023, 05:41:23 UTC Fix crash with RemoveFromWaitQueue() when detecting a deadlock. Commit 5764f611e used dclist_delete_from() to remove the proc from the wait queue. However, since it doesn't clear dist_node's next/prev to NULL, it could call RemoveFromWaitQueue() twice: when the process detects a deadlock and then when cleaning up locks on aborting the transaction. The waiting lock information is cleared in the first call, so it led to a crash in the second call. Backpatch to v16, where the change was introduced. Bug: #18031 Reported-by: Justin Pryzby, Alexander Lakhin Reviewed-by: Andres Freund Discussion: https://postgr.es/m/ZKy4AdrLEfbqrxGJ%40telsasoft.com Discussion: https://postgr.es/m/18031-ebe2d08cb405f6cc@postgresql.org Backpatch-through: 16 26 July 2023, 05:41:23 UTC
35c85c3 Masahiko Sawada 25 July 2023, 06:09:31 UTC Remove unnecessary checks for indexes for REPLICA IDENTITY FULL tables. Previously, when selecting an usable index for update/delete for the REPLICA IDENTITY FULL table, in IsIndexOnlyExpression(), we used to check if all index fields are not expressions. However, it was not necessary, because it is enough to check if only the leftmost index field is not an expression (and references the remote table column) and this check has already been done by RemoteRelContainsLeftMostColumnOnIdx(). This commit removes IsIndexOnlyExpression() and RemoteRelContainsLeftMostColumnOnIdx() and all checks for usable indexes for REPLICA IDENTITY FULL tables are now performed by IsIndexUsableForReplicaIdentityFull(). Backpatch this to remain the code consistent. Reported-by: Peter Smith Reviewed-by: Amit Kapila, Önder Kalacı Discussion: https://postgr.es/m/CAHut%2BPsGRE5WSsY0jcLHJEoA17MrbP9yy8FxdjC_ZOAACxbt%2BQ%40mail.gmail.com Backpatch-through: 16 25 July 2023, 06:09:31 UTC
ad486b0 Amit Kapila 25 July 2023, 03:31:29 UTC Fix the display of UNKNOWN message type in apply worker. We include the message type while displaying an error context in the apply worker. Now, while retrieving the message type string if the message type is unknown we throw an error that will hide the original error. So, instead, we need to simply return the string indicating an unknown message type. Reported-by: Ashutosh Bapat Author: Euler Taveira, Amit Kapila Reviewed-by: Ashutosh Bapat Backpatch-through: 15 Discussion: https://postgr.es/m/CAExHW5suAEDW-mBZt_qu4RVxWZ1vL54-L+ci2zreYWebpzxYsA@mail.gmail.com 25 July 2023, 03:31:29 UTC
bd2f46c Andres Freund 25 July 2023, 02:07:52 UTC Fix off-by-one in LimitAdditionalPins() Due to the bug LimitAdditionalPins() could return 0, violating LimitAdditionalPins()'s API ("One additional pin is always allowed"). This could be hit when setting shared_buffers very low and using a fair amount of concurrency. This bug was introduced in 31966b151e6a. Author: "Anton A. Melnikov" <aamelnikov@inbox.ru> Reported-by: "Anton A. Melnikov" <aamelnikov@inbox.ru> Reported-by: Victoria Shepard Discussion: https://postgr.es/m/ae46f2fb-5586-3de0-b54b-1bb0f6410ebd@inbox.ru Backpatch: 16- 25 July 2023, 02:11:51 UTC
b1dc946 Alvaro Herrera 24 July 2023, 15:48:06 UTC Make test_decoding ddl.out shorter Some of the test_decoding test output was extremely wide, because it deals with massive toasted values, and the aligned mode causes psql to produce 200kB of whitespace and dashes. Change to unaligned mode temporarily to avoid that behavior. Backpatch to 14, where it applies cleanly. Discussion: https://postgr.es/m/20230405103953.sxleixp3uz5lazst@alvherre.pgsql 24 July 2023, 15:48:06 UTC
28ce9d5 Alvaro Herrera 24 July 2023, 15:14:22 UTC Compare only major versions in AdjustUpgrade.pm Because PostgreSQL::Version is very nuanced about development version numbers, the comparison to 16beta2 makes it think that that release is older than 16, therefore applying a database tweak that doesn't work there (the comparison is only supposed to match when run on version 15). As suggested by Andrew Dunstan, fix by having AdjustUpgrade.pm public methods create a separate PostgreSQL::Version object to use for these comparisons, that only carries the major version number. While at it, have the same methods ensure that the objects given are of the expected type. Backpatch to 16. This module goes all the way back to 9.2, but there's probably no need for this fix except where betas still live. Co-authored-by: Andrew Dunstan <andrew@dunslane.net> Discussion: https://postgr.es/m/20230719110504.zbu74o54bqqlsufb@alvherre.pgsql 24 July 2023, 15:14:22 UTC
11237e5 Tom Lane 22 July 2023, 14:32:52 UTC Avoid compiler warning in non-assert builds. After 3c90dcd03, try_partitionwise_join's child_joinrelids variable is read only in an Assert, provoking a compiler warning in non-assert builds. Rearrange code to avoid the warning and eliminate unnecessary work in the non-assert case. Per CI testing (via Jeff Davis and Bharath Rupireddy) Discussion: https://postgr.es/m/ef0de9713e605451f1b60b30648c5ee900b2394c.camel@j-davis.com 22 July 2023, 14:32:52 UTC
f75595c Tom Lane 21 July 2023, 16:00:14 UTC Fix calculation of relid sets for partitionwise child joins. Applying add_outer_joins_to_relids() to a child join doesn't actually work, even if we've built a SpecialJoinInfo specialized to the child, because that function will also compare the join's relids to elements of the main join_info_list, which only deal in regular relids not child relids. This mistake escaped detection by the existing partitionwise join tests because they didn't test any cases where add_outer_joins_to_relids() needs to add additional OJ relids (that is, any cases where join reordering per identity 3 is possible). Instead, let's apply adjust_child_relids() to the relids of the parent join. This requires minor code reordering to collect the relevant AppendRelInfo structures first, but that's work we'd do shortly anyway. Report and fix by Richard Guo; cosmetic changes by me Discussion: https://postgr.es/m/CAMbWs49NCNbyubZWgci3o=_OTY=snCfAPtMnM-32f3mm-K-Ckw@mail.gmail.com 21 July 2023, 16:00:14 UTC
66a9003 Amit Langote 21 July 2023, 10:28:31 UTC Don't include CaseTestExpr in JsonValueExpr.formatted_expr A CaseTestExpr is currently being put into JsonValueExpr.formatted_expr as placeholder for the result of evaluating JsonValueExpr.raw_expr, which in turn is evaluated separately. Though, there's no need for this indirection if raw_expr itself can be embedded into formatted_expr and evaluated as part of evaluating the latter, especially as there is no special reason to evaluate it separately. So this commit makes it so. As a result, JsonValueExpr.raw_expr no longer needs to be evaluated in ExecInterpExpr(), eval_const_exprs_mutator() etc. and is now only used for displaying the original "unformatted" expression in ruleutils.c. Comments about and the code manipulating formatted_expr is updated to mention that it is now always set and is the expression that gives a JsonValueExpr its runtime value. While at it, this also removes the function makeCaseTestExpr(), because the code in makeJsonConstructorExpr() looks more readable without it IMO and isn't used by anyone else either. Finally, a note is added in the comment above CaseTestExpr's definition that JsonConstructorExpr is also using it. Backpatched to 16 from the development branch to keep the code in sync across branches. Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Discussion: https://postgr.es/m/CA+HiwqE4XTdfb1nW=Ojoy_tQSRhYt-q_kb6i5d4xcKyrLC1Nbg@mail.gmail.com 21 July 2023, 10:28:31 UTC
c0f5313 Tom Lane 20 July 2023, 18:23:46 UTC Guard against null plan pointer in CachedPlanIsSimplyValid(). If both the passed-in plan pointer and plansource->gplan are NULL, CachedPlanIsSimplyValid would think that the plan pointer is possibly-valid and try to dereference it. For the one extant call site in plpgsql, this situation doesn't normally happen which is why we've not noticed. However, it appears to be possible if the previous use of the cached plan failed, as per report from Justin Pryzby. Add an extra check to prevent crashing. Back-patch to v13 where this code was added. Discussion: https://postgr.es/m/ZLlV+STFz1l/WhAQ@telsasoft.com 20 July 2023, 18:23:46 UTC
7825a1b Amit Langote 20 July 2023, 07:23:49 UTC Pass constructName to transformJsonValueExpr() This allows it to pass to coerce_to_specific_type() the actual name corresponding to the specific JSON_* function expression being transformed, instead of the currently hardcoded string. Backpatched to 16 from the development branch to keep the code in sync across branches. Reviewed-by: Álvaro Herrera <alvherre@alvh.no-ip.org> Discussion: https://postgr.es/m/CA+HiwqHu58pO3cJ7rB6ZLwUztVdG1J66xSjDdjfan5uT5NhESw@mail.gmail.com 20 July 2023, 08:15:15 UTC
0a1d2a7 Tom Lane 19 July 2023, 16:46:30 UTC Add psql \drg command to display role grants. With the addition of INHERIT and SET options for role grants, the historical display of role memberships in \du/\dg is woefully inadequate. Besides those options, there are pre-existing shortcomings that you can't see the ADMIN option nor the grantor. To fix this, remove the "Member of" column from \du/\dg altogether (making that output usefully narrower), and invent a new meta-command "\drg" that is specifically for displaying role memberships. It shows one row for each role granted to the selected role(s), with the grant options and grantor. We would not normally back-patch such a feature addition post feature freeze, but in this case the change is mainly driven by v16 changes in the server, so it seems appropriate to include it in v16. Pavel Luzanov, with bikeshedding and review from a lot of people, but particularly David Johnston Discussion: https://postgr.es/m/b9be2d0e-a9bc-0a30-492f-a4f68e4f7740@postgrespro.ru 19 July 2023, 16:46:30 UTC
245d0e6 Tom Lane 19 July 2023, 15:00:34 UTC Doc: improve description of IN and row-constructor comparisons. IN and NOT IN work fine on records and arrays, so just say that they accept "expressions" not "scalar expressions". I think that that phrasing was meant to say that they don't work on set-returning expressions, but that's not the common meaning of "scalar". Revise the description of row-constructor comparisons to make it perhaps a bit less confusing. (This partially reverts some dubious wording changes made by commit f56651519.) Per gripe from Ilya Nenashev. Back-patch to supported branches. In HEAD and v16, also drop a NOTE about pre-8.2 behavior, which is hopefully no longer of interest to anybody. Discussion: https://postgr.es/m/168968062460.632.14303906825812821399@wrigleys.postgresql.org 19 July 2023, 15:00:34 UTC
e6e451c Tom Lane 18 July 2023, 15:59:39 UTC Doc: fix out-of-date example of SPI usage. The "count" argument of SPI_exec() only limits execution when the query is actually returning rows. This was not the case before PG 9.0, so this example was correct when written; but we missed updating it in commit 2ddc600f8. Extend the example to show the behavior both with and without RETURNING. While here, improve the commentary and markup for the rest of the example. David G. Johnston and Tom Lane, per report from Curt Kolovson. Back-patch to all supported branches. Discussion: https://postgr.es/m/CANhYJV6HWtgz_qjx_APfK0PAgLUzY-2vjLuj7i_o=TZF1LAQew@mail.gmail.com 18 July 2023, 15:59:39 UTC
926aa6d Michael Paquier 18 July 2023, 05:04:46 UTC Fix indentation in twophase.c This has been missed in cb0cca1, noticed before buildfarm member koel has been able to complain while poking at a different patch. Like the other commit, backpatch all the way down to limit the odds of merge conflicts. Backpatch-through: 11 18 July 2023, 05:04:46 UTC
f88bc9f Michael Paquier 18 July 2023, 04:44:27 UTC Fix recovery of 2PC transaction during crash recovery A crash in the middle of a checkpoint with some two-phase state data already flushed to disk by this checkpoint could cause a follow-up crash recovery to recover twice the same transaction, once from what has been found in pg_twophase/ at the beginning of recovery and a second time when replaying its corresponding record. This would lead to FATAL failures in the startup process during recovery, where the same transaction would have a state recovered twice instead of once: LOG: recovering prepared transaction 731 from shared memory LOG: recovering prepared transaction 731 from shared memory FATAL: lock ExclusiveLock on object 731/0/0 is already held This issue is fixed by skipping the addition of any 2PC state coming from a record whose equivalent 2PC state file has already been loaded in TwoPhaseState at the beginning of recovery by restoreTwoPhaseData(), which is OK as long as the system has not reached a consistent state. The timing to get a messed up recovery processing is very racy, and would very unlikely happen. The thread that has reported the issue has demonstrated the bug using injection points to force a PANIC in the middle of a checkpoint. Issue introduced in 728bd99, so backpatch all the way down. Reported-by: "suyu.cmj" <mengjuan.cmj@alibaba-inc.com> Author: "suyu.cmj" <mengjuan.cmj@alibaba-inc.com> Author: Michael Paquier Discussion: https://postgr.es/m/109e6994-b971-48cb-84f6-829646f18b4c.mengjuan.cmj@alibaba-inc.com Backpatch-through: 11 18 July 2023, 04:44:27 UTC
efe8d82 Tom Lane 17 July 2023, 20:54:54 UTC Include <limits.h> in fe-auth.c, to get CHAR_BIT reliably. fe-auth.c references CHAR_BIT since commit 3a465cc67, but it did not #include <limits.h>, which per POSIX is where that symbol is defined. This escaped notice so far because (a) on most platforms, <sys/param.h> pulls in <limits.h>, (b) even if yours doesn't, OpenSSL pulls it in, so compiling with --with-openssl masks the omission. Per bug #18026 from Marcel Hofstetter. Back-patch to v16. Discussion: https://postgr.es/m/18026-d5bb69f79cd16203@postgresql.org 17 July 2023, 20:54:54 UTC
4a7301c Amit Langote 14 July 2023, 05:28:38 UTC Add missing initializations of p_perminfo In a61b1f74823, we failed to update transformFromClauseItem() and buildNSItemFromLists() to set ParseNamespaceItem.p_perminfo causing it to point to garbage. Pointed out by Tom Lane. Reported-by: Farias de Oliveira <matheusfarias519@gmail.com> Discussion: https://postgr.es/m/3173476.1689286373%40sss.pgh.pa.us Backpatch-through: 16 14 July 2023, 05:55:42 UTC
27da471 Michael Paquier 14 July 2023, 02:16:03 UTC Add indisreplident to fields refreshed by RelationReloadIndexInfo() RelationReloadIndexInfo() is a fast-path used for index reloads in the relation cache, and it has always forgotten about updating indisreplident, which is something that would happen after an index is selected for a replica identity. This can lead to incorrect cache information provided when executing a command in a transaction context that updates indisreplident. None of the code paths currently on HEAD that need to check upon pg_index.indisreplident fetch its value from the relation cache, always relying on a fresh copy on the syscache. Unfortunately, this may not be the case of out-of-core code, that could see out-of-date value. Author: Shruthi Gowda Reviewed-by: Robert Haas, Dilip Kumar, Michael Paquier Discussion: https://postgr.es/m/CAASxf_PBcxax0wW-3gErUyftZ0XrCs3Lrpuhq4-Z3Fak1DoW7Q@mail.gmail.com Backpatch-through: 11 14 July 2023, 02:16:03 UTC
31f9d41 Michael Paquier 14 July 2023, 01:13:14 UTC Fix updates of indisvalid for partitioned indexes indisvalid is switched to true for partitioned indexes when all its partitions have valid indexes when attaching a new partition, up to the top-most parent if all its leaves are themselves valid when dealing with multiple layers of partitions. The copy of the tuple from pg_index used to switch indisvalid to true came from the relation cache, which is incorrect. Particularly, in the case reported by Shruthi Gowda, executing a series of commands in a single transaction would cause the validation of partitioned indexes to use an incorrect version of a pg_index tuple, as indexes are reloaded after an invalidation request with RelationReloadIndexInfo(), a much faster version than a full index cache rebuild. In this case, the limited information updated in the cache leads to an incorrect version of the tuple used. One of the symptoms reported was the following error, with a replica identity update, for instance: "ERROR: attempted to update invisible tuple" This is incorrect since 8b08f7d, so backpatch all the way down. Reported-by: Shruthi Gowda Author: Michael Paquier Reviewed-by: Shruthi Gowda, Dilip Kumar Discussion: https://postgr.es/m/CAASxf_PBcxax0wW-3gErUyftZ0XrCs3Lrpuhq4-Z3Fak1DoW7Q@mail.gmail.com Backpatch-through: 11 14 July 2023, 01:13:14 UTC
a4b4cc1 Andres Freund 13 July 2023, 20:03:30 UTC Handle DROP DATABASE getting interrupted Until now, when DROP DATABASE got interrupted in the wrong moment, the removal of the pg_database row would also roll back, even though some irreversible steps have already been taken. E.g. DropDatabaseBuffers() might have thrown out dirty buffers, or files could have been unlinked. But we continued to allow connections to such a corrupted database. To fix this, mark databases invalid with an in-place update, just before starting to perform irreversible steps. As we can't add a new column in the back branches, we use pg_database.datconnlimit = -2 for this purpose. An invalid database cannot be connected to anymore, but can still be dropped. Unfortunately we can't easily add output to psql's \l to indicate that some database is invalid, it doesn't fit in any of the existing columns. Add tests verifying that a interrupted DROP DATABASE is handled correctly in the backend and in various tools. Reported-by: Evgeny Morozov <postgresql3@realityexists.net> Author: Andres Freund <andres@anarazel.de> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Reviewed-by: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/20230509004637.cgvmfwrbht7xm7p6@awork3.anarazel.de Discussion: https://postgr.es/m/20230314174521.74jl6ffqsee5mtug@awork3.anarazel.de Backpatch: 11-, bug present in all supported versions 13 July 2023, 20:03:30 UTC
03ccc95 Andres Freund 13 July 2023, 20:03:30 UTC Release lock after encountering bogs row in vac_truncate_clog() When vac_truncate_clog() encounters bogus datfrozenxid / datminmxid values, it returns early. Unfortunately, until now, it did not release WrapLimitsVacuumLock. If the backend later tries to acquire WrapLimitsVacuumLock, the session / autovacuum worker hangs in an uncancellable way. Similarly, other sessions will hang waiting for the lock. However, if the backend holding the lock exited or errored out for some reason, the lock was released. The bug was introduced as a side effect of 566372b3d643. It is interesting that there are no production reports of this problem. That is likely due to a mix of bugs leading to bogus values having gotten less common, process exit releasing locks and instances of hangs being hard to debug for "normal" users. Discussion: https://postgr.es/m/20230621221208.vhsqgduwfpzwxnpg@awork3.anarazel.de 13 July 2023, 20:03:30 UTC
e27f3f5 Tom Lane 13 July 2023, 17:07:51 UTC Remove unnecessary pfree() in g_intbig_compress(). GiST compress functions (like all GiST opclass functions) are supposed to be called in short-lived memory contexts, so that minor memory leaks in them are not of concern, and indeed explicit pfree's are likely slightly counterproductive. But this one in g_intbig_compress() is more than slightly counterproductive, because it's guarded by "if (in != DatumGetArrayTypeP(entry->key))" which means that if this test succeeds, we've detoasted the datum twice. (And to add insult to injury, the extra detoast result is leaked.) Let's just drop the whole stanza, relying on the GiST temporary context mechanism to clean up in good time. The analogous bit in g_int_compress() is if (r != (ArrayType *) DatumGetPointer(entry->key)) pfree(r); which doesn't have the gratuitous-detoast problem so I left it alone. Perhaps there is a case for removing unnecessary pfree's more widely, but I'm not sure if it's worth the code churn. The potential extra decompress seems expensive enough to justify calling this a (minor) performance bug and back-patching. Konstantin Knizhnik, Matthias van de Meent, Tom Lane Discussion: https://postgr.es/m/CAEze2Wi86=DxErfvf+SCB2UKmU2amKOF60BKuJOX=w-RojRn0A@mail.gmail.com 13 July 2023, 17:08:08 UTC
b4018ec Peter Eisentraut 13 July 2023, 10:56:35 UTC Fix untranslatable log message assembly We can't inject the name of the logical replication worker into a log message like that. But for these messages we don't really need the precision of knowing what kind of worker it was, so just write "logical replication worker" and keep the message in one piece. Discussion: https://www.postgresql.org/message-id/flat/CAHut%2BPt1xwATviPGjjtJy5L631SGf3qjV9XUCmxLu16cHamfgg%40mail.gmail.com 13 July 2023, 11:21:33 UTC
4946910 Masahiko Sawada 13 July 2023, 06:03:24 UTC Doc: clarify the conditions of usable indexes for REPLICA IDENTITY FULL tables. Commit 89e46da5e allowed REPLICA IDENTITY FULL tables to use an index on the subscriber during apply of update/delete. This commit clarifies in the documentation that the leftmost field of candidate indexes must be a column (not an expression) that references the published relation column. The source code comments are also updated accordingly. Reviewed-by: Peter Smith, Amit Kapila Discussion: https://postgr.es/m/CAD21AoDJjffEvUFKXT27Q5U8-UU9JHv4rrJ9Ke8Zkc5UPWHLvA@mail.gmail.com Backpatch-through: 16 13 July 2023, 06:03:24 UTC
back to top