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
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
7fc064d Andres Freund 12 July 2023, 23:26:03 UTC meson: Tie adding C++ support to the llvm Meson option In the event the llvm option is defined to be 'auto', it is possible that the host machine might not have a C++ compiler. If that is the case, then we shouldn't continue reaching for the llvm dependency. To make it easier to understand the case where LLVM support is disabled due to lacking a C++ compiler, add a message noting that fact. Author: Tristan Partin <tristan@neon.tech> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CSPIJVUDZFKX.3KHMOAVGF94RV@c3po Backpatch: 16-, where meson support was added 12 July 2023, 23:26:03 UTC
5a7280d Andres Freund 12 July 2023, 23:26:03 UTC meson: Pass more feature option through to required kwargs That was already done in a lot of places, but not all. Backpatch this to keep the the meson files aligned as long as reasonably possible. Author: Tristan Partin <tristan@neon.tech> Reviewed-by: Andres Freund <andres@anarazel.de> Discussion: https://postgr.es/m/CSPIJVUDZFKX.3KHMOAVGF94RV@c3po Backpatch: 16-, where meson support was added 12 July 2023, 23:26:03 UTC
eeb28a2 Andres Freund 12 July 2023, 23:26:03 UTC pg_bsd_indent: Collect test diffs in test.diffs instead of tests.diff That way CI knows to pick up the file if the test fails. Discussion: https://postgr.es/m/20230711233307.hu4wetabjm5f7ver@awork3.anarazel.de Backpatch: 16-, where the test was added 12 July 2023, 23:26:03 UTC
93dcdfa Tom Lane 10 July 2023, 16:14:34 UTC Be more rigorous about local variables in PostgresMain(). Since PostgresMain calls sigsetjmp, any local variables that are not marked "volatile" have a risk of unspecified behavior. In practice this means that when control returns via longjmp, such variables might get reset to their values as of the time of sigsetjmp, depending on whether the compiler chose to put them in registers or on the stack. We were careful about this for "send_ready_for_query", but not the other local variables. In the case of the timeout_enabled flags, resetting them to their initial "false" states is actually good, since we do "disable_all_timeouts()" in the longjmp cleanup code path. If that does not happen, we risk uselessly calling "disable_timeout()" later, which is harmless but a little bit expensive. Let's explicitly reset these flags so that the behavior is correct and platform-independent. (This change means that we really don't need the new "volatile" markings after all, but let's install them anyway since any change in this logic could re-introduce a problem.) There is no issue for "firstchar" and "input_message" because those are explicitly reinitialized each time through the query processing loop. To make that clearer, move them to be declared inside the loop. That leaves us with all the function-lifespan locals except the sigjmp_buf itself marked as volatile, which seems like a good policy to have going forward. Because of the possibility of extra disable_timeout() calls, this seems worth back-patching. Sergey Shinderuk and Tom Lane Discussion: https://postgr.es/m/2eda015b-7dff-47fd-d5e2-f1a9899b90a6@postgrespro.ru 10 July 2023, 16:14:34 UTC
e004cb0 Peter Eisentraut 10 July 2023, 10:05:32 UTC Fix pgindent for commit e53a611523 10 July 2023, 10:05:51 UTC
2631eba Peter Eisentraut 10 July 2023, 08:46:54 UTC Message wording improvements 10 July 2023, 08:46:54 UTC
55c95f2 Michael Paquier 10 July 2023, 00:40:12 UTC Fix ALTER EXTENSION SET SCHEMA with objects outside an extension's schema As coded, the code would use as a base comparison the namespace OID from the first object scanned in pg_depend when switching its namespace dependency entry to the new one, and use it as a base of comparison for any follow-up checks. It would also be used as the old namespace OID to switch *from* for the extension's pg_depend entry. Hence, if the first object scanned has a namespace different than the one stored in the extension, we would finish by: - Not checking that the extension objects map with the extension's schema. - Not switching the extension -> namespace dependency entry to the new namespace provided by the user, making ALTER EXTENSION ineffective. This issue exists since this command has been introduced in d9572c4 for relocatable extension, so backpatch all the way down to 11. The test case has been provided by Heikki, that I have tweaked a bit to show the effects on pg_depend for the extension. Reported-by: Heikki Linnakangas Author: Michael Paquier, Heikki Linnakangas Discussion: https://postgr.es/m/20eea594-a05b-4c31-491b-007b6fceef28@iki.fi Backpatch-through: 11 10 July 2023, 00:40:12 UTC
25da5cd Peter Eisentraut 09 July 2023, 08:02:15 UTC doc: Use proper markup for emphasis 09 July 2023, 08:02:56 UTC
1da1cd2 Peter Eisentraut 09 July 2023, 07:46:24 UTC doc: Move DEFAULT parameter on COPY reference page The DEFAULT parameter seems most similar to the NULL parameter, so move it next to it, instead of having it at the end of the parameter list because it was the last one added. 09 July 2023, 07:46:24 UTC
6d8b5f4 David Rowley 09 July 2023, 04:14:47 UTC Doc: update old reference to "result cache" During the PostgreSQL 14 cycle, the Memoize executor node was briefly called "Result Cache" until it was renamed in 83f4fcc65. That commit missed one reference. Reported-by: Paul A Jungwirth Packpatch-through: 14, where Memoize was added Discussion: https://postgr.es/m/CA+renyX=40YXhsfPTzn13oNOPO3TJ12CK9GX-2P2pvnQiScefA@mail.gmail.com 09 July 2023, 04:14:47 UTC
6d8a8bb Andrew Dunstan 08 July 2023, 16:34:25 UTC Fix tmpdir issues with commit e213de8e78 Commit e213de8e78 fixed a problem with path lengths to a tempdir on Windows, but caused problems on at least some Unix systems where the system tempdir is on a different file system. To work around this, only used the system temdir for the destination of pg_replslot on Windows, and otherwise restore the old behaviour. Backpatch to relase 14 like the previous patch. Problem exposed by a myriad of buildfarm animals. 08 July 2023, 16:37:41 UTC
67ece2e Andrew Dunstan 08 July 2023, 15:21:58 UTC Use shorter location for pg_replslot in pg_basebackup test The symlink to a longer location tripped up some Windows limit on buildfarm animal fairywren when running with meson, which uses slightly longer paths. Backpatch to all live branches to keep the script in sync. 08 July 2023, 15:48:20 UTC
1421e8f Peter Eisentraut 08 July 2023, 15:24:41 UTC Fix Perl warning Use of uninitialized value $content in concatenation (.) or string 08 July 2023, 15:24:41 UTC
01f1f78 Peter Eisentraut 08 July 2023, 13:50:35 UTC Make some indentation in gram.y consistent Reviewed-by: Amit Langote <amitlangote09@gmail.com> Discussion: https://www.postgresql.org/message-id/flat/CA+HiwqE4XTdfb1nW=Ojoy_tQSRhYt-q_kb6i5d4xcKyrLC1Nbg@mail.gmail.com 08 July 2023, 13:50:35 UTC
9574459 Nathan Bossart 07 July 2023, 18:25:23 UTC Revert MAINTAIN privilege and pg_maintain predefined role. This reverts the following commits: 4dbdb82513, c2122aae63, 5b1a879943, 9e1e9d6560, ff9618e82a, 60684dd834, 4441fc704d, and b5d6382496. A role with the MAINTAIN privilege may be able to use search_path tricks to escalate privileges to the table owner. Unfortunately, it is too late in the v16 development cycle to apply the proposed fix, i.e., restricting search_path when running maintenance commands. Bumps catversion. Reviewed-by: Jeff Davis Discussion: https://postgr.es/m/E1q7j7Y-000z1H-Hr%40gemulon.postgresql.org Backpatch-through: 16 07 July 2023, 18:25:23 UTC
1124cb2 Tomas Vondra 07 July 2023, 17:04:32 UTC Document relaxed HOT for summarizing indexes Commit 19d8e2308b allowed a weaker check for HOT with summarizing indexes, but it did not update README.HOT. So do that now. Patch by Matthias van de Meent, minor changes by me. Backpatch to 16, where the optimization was introduced. Author: Matthias van de Meent Reviewed-by: Tomas Vondra Backpatch-through: 16 Discussion: https://postgr.es/m/CAEze2WiEOm8V+c9kUeYp2BPhbEc5s473fUf51xNeqvSFGv44Ew@mail.gmail.com 07 July 2023, 17:05:36 UTC
727d965 Andres Freund 06 July 2023, 15:34:17 UTC Fix type of iterator variable in SH_START_ITERATE Also add comment to make the reasoning behind the Assert() more explicit (per Tom). Reported-by: Ranier Vilela Discussion: https://postgr.es/m/CAEudQAocXNJ6s1VLz+hMamLAQAiewRoW17OJ6-+9GACKfj6iPQ@mail.gmail.com Backpatch: 11- 06 July 2023, 16:57:29 UTC
b94d70a Andrew Dunstan 06 July 2023, 16:27:40 UTC Skip pg_baseback long filename test if path too long on Windows On Windows, it's sometimes difficult to create a file with a path longer than 255 chars, and if it can be created it might not be seen by the archiver. This can be triggered by the test for tar backups with filenames greater than 100 bytes. So we skip that test if the path would exceed 255. Backpatch to all live branches. Reviewed by Daniel Gustafsson Discussion: https://postgr.es/m/666ac55b-3400-fb2c-2cea-0281bf36a53c@dunslane.net 06 July 2023, 16:36:13 UTC
bf7b70e Heikki Linnakangas 06 July 2023, 14:25:29 UTC WAL-log the creation of the init fork of unlogged indexes. We create a file, so we better WAL-log it. In practice, all the built-in index AMs and all extensions that I'm aware of write a metapage to the init fork, which is WAL-logged, and replay of the metapage implicitly creates the fork too. But if ambuildempty() didn't write any page, we would miss it. This can be seen with dummy_index_am. Set up replication, create a 'dummy_index_am' index on an unlogged table, and look at the files created in the replica: the init fork is not created on the replica. Dummy_index_am doesn't do anything with the relation files, however, so it doesn't lead to any user-visible errors. Backpatch to all supported versions. Reviewed-by: Robert Haas Discussion: https://www.postgresql.org/message-id/6e5bbc08-cdfc-b2b3-9e23-1a914b9850a9%40iki.fi 06 July 2023, 14:28:50 UTC
3c1adbb Amit Kapila 06 July 2023, 03:11:30 UTC Revert the commits related to allowing page lock to conflict among parallel group members. This commit reverts the work done by commits 3ba59ccc89 and 72e78d831a. Those commits were incorrect in asserting that we never acquire any other heavy-weight lock after acquring page lock other than relation extension lock. We can acquire a lock on catalogs while doing catalog look up after acquring page lock. This won't impact any existing feature but we need to think some other way to achieve this before parallelizing other write operations or even improving the parallelism in vacuum (like allowing multiple workers for an index). Reported-by: Jaime Casanova Author: Amit Kapila Backpatch-through: 13 Discussion: https://postgr.es/m/CAJKUy5jffnRKNvRHKQ0LynRb0RJC-o4P8Ku3x9vGAVLwDBWumQ@mail.gmail.com 06 July 2023, 03:11:30 UTC
dc0b584 Heikki Linnakangas 05 July 2023, 10:13:13 UTC Fix leak of LLVM "fatal-on-oom" section counter. llvm_release_context() called llvm_enter_fatal_on_oom(), but was missing the corresponding llvm_leave_fatal_on_oom() call. As a result, if JIT was used at all, we were almost always in the "fatal-on-oom" state. It only makes a difference if you use an extension written in C++, and run out of memory in a C++ 'new' call. In that case, you would get a PostgreSQL FATAL error, instead of the default behavior of throwing a C++ exception. Back-patch to all supported versions. Reviewed-by: Daniel Gustafsson Discussion: https://www.postgresql.org/message-id/54b78cca-bc84-dad8-4a7e-5b56f764fab5@iki.fi 05 July 2023, 10:25:59 UTC
be8cae7 Masahiko Sawada 05 July 2023, 05:49:58 UTC pgstat: fix subscription stats entry leak. Commit 7b64e4b3 taught DropSubscription() to drop stats entry of subscription that is not associated with a replication slot for apply worker at DROP SUBSCRIPTION but missed covering the case where the subscription is not associated with replication slots for both apply worker and tablesync worker. Also add a test to verify that the stats for slot-less subscription is removed at DROP SUBSCRIPTION time. Backpatch down to 15. Author: Masahiko Sawada Reviewed-by: Nathan Bossart, Hayato Kuroda, Melih Mutlu, Amit Kapila Discussion: https://postgr.es/m/CAD21AoB71zkP7uPT7JDPsZcvp0749ExEQnOJxeNKPDFisHar+w@mail.gmail.com Backpatch-through: 15 05 July 2023, 05:49:58 UTC
eb27d3d Daniel Gustafsson 04 July 2023, 15:36:13 UTC Fix assertion failure in snapshot building Clear any potential stale next_phase_at value from the snapshot builder which otherwise may trip an assertion check ensuring that there is no next_phase_at value. This can be reproduced by running 80 concurrent sessions like the below where $c is a loop counter (assumes there has been 1..$c databases created) : echo " CREATE TABLE replication_example(id SERIAL PRIMARY KEY, somedata int, text varchar(120)); SELECT 'init' FROM pg_create_logical_replication_slot('regression_slot_$c', 'test_decoding'); SELECT data FROM pg_logical_slot_get_changes('regression_slot_$c', NULL, NULL, 'include-xids', '0', 'skip-empty-xacts', '1'); " | psql -d regress_$c >>psql.log & Backpatch down to v16. Bug: #17695 Author: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-by: Alexander Lakhin <exclusion@gmail.com> Reported-by: bowenshi <zxwsbg@qq.com> Discussion: https://postgr.es/m/17695-6be9277c9295985f@postgresql.org Backpatch-through: v16 04 July 2023, 15:36:13 UTC
d431644 Heikki Linnakangas 04 July 2023, 14:57:03 UTC Ensure that creation of an empty relfile is fsync'd at checkpoint. If you create a table and don't insert any data into it, the relation file is never fsync'd. You don't lose data, because an empty table doesn't have any data to begin with, but if you crash and lose the file, subsequent operations on the table will fail with "could not open file" error. To fix, register an fsync request in mdcreate(), like we do for mdwrite(). Per discussion, we probably should also fsync the containing directory after creating a new file. But that's a separate and much wider issue. Backpatch to all supported versions. Reviewed-by: Andres Freund, Thomas Munro Discussion: https://www.postgresql.org/message-id/d47d8122-415e-425c-d0a2-e0160829702d%40iki.fi 04 July 2023, 15:04:27 UTC
af8f9ec Thomas Munro 04 July 2023, 03:16:34 UTC Re-bin segment when memory pages are freed. It's OK to be lazy about re-binning memory segments when allocating, because that can only leave segments in a bin that's too high. We'll search higher bins if necessary while allocating next time, and also eventually re-bin, so no memory can become unreachable that way. However, when freeing memory, the largest contiguous range of free pages might go up, so we should re-bin eagerly to make sure we don't leave the segment in a bin that is too low for get_best_segment() to find. The re-binning code is moved into a function of its own, so it can be called whenever free pages are returned to the segment's free page map. Back-patch to all supported releases. Author: Dongming Liu <ldming101@gmail.com> Reviewed-by: Robert Haas <robertmhaas@gmail.com> (earlier version) Reviewed-by: Thomas Munro <thomas.munro@gmail.com> Discussion: https://postgr.es/m/CAL1p7e8LzB2LSeAXo2pXCW4%2BRya9s0sJ3G_ReKOU%3DAjSUWjHWQ%40mail.gmail.com 04 July 2023, 03:21:36 UTC
1252902 Thomas Munro 03 July 2023, 04:20:01 UTC Fix race in SSI interaction with gin fast path. The ginfast.c code previously checked for conflicts in before locking the relevant buffer, leaving a window where a RW conflict could be missed. Re-order. There was also a place where buffer ID and block number were confused while trying to predicate-lock a page, noted by visual inspection. Back-patch to all supported releases. Fixes one more problem discovered with the reproducer from bug #17949, in this case when Dmitry tried other index types. Reported-by: Artem Anisimov <artem.anisimov.255@gmail.com> Reported-by: Dmitry Dolgov <9erthalion6@gmail.com> Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Discussion: https://postgr.es/m/17949-a0f17035294a55e2%40postgresql.org 03 July 2023, 21:04:35 UTC
d03d9a2 Thomas Munro 03 July 2023, 04:18:20 UTC Fix race in SSI interaction with bitmap heap scan. When performing a bitmap heap scan, we don't want to miss concurrent writes that occurred after we observed the heap's rs_nblocks, but before we took predicate locks on index pages. Therefore, we can't skip fetching any heap tuples that are referenced by the index, because we need to test them all with CheckForSerializableConflictOut(). The old optimization that would ignore any references to blocks >= rs_nblocks gets in the way of that requirement, because it means that concurrent writes in that window are ignored. Removing that optimization shouldn't affect correctness at any isolation level, because any new tuples shouldn't be visible to an MVCC snapshot. There also shouldn't be any error-causing references to heap blocks past the end, because we should have held at least an AccessShareLock on the table before the index scan. It can't get smaller while our transaction is running. For now, though, we'll keep the optimization at lower levels to avoid making unnecessary changes in a bug fix. Back-patch to all supported releases. In release 11, the code is in a different place but not fundamentally different. Fixes one aspect of bug #17949. Reported-by: Artem Anisimov <artem.anisimov.255@gmail.com> Reviewed-by: Dmitry Dolgov <9erthalion6@gmail.com> Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Discussion: https://postgr.es/m/17949-a0f17035294a55e2%40postgresql.org 03 July 2023, 21:04:35 UTC
0cb1fb2 Thomas Munro 03 July 2023, 04:16:27 UTC Fix race in SSI interaction with empty btrees. When predicate-locking btrees, we have a special case for completely empty btrees, since there is no page to lock. This was racy, because, without buffer lock held, a matching key could be inserted between the _bt_search() and the PredicateLockRelation() calls. Fix, by rechecking _bt_search() after taking the relation-level SIREAD lock, if using SERIALIZABLE isolation and an empty btree is discovered. Back-patch to all supported releases. Fixes one aspect of bug #17949. Reported-by: Artem Anisimov <artem.anisimov.255@gmail.com> Reviewed-by: Dmitry Dolgov <9erthalion6@gmail.com> Reviewed-by: Heikki Linnakangas <hlinnaka@iki.fi> Discussion: https://postgr.es/m/17949-a0f17035294a55e2%40postgresql.org 03 July 2023, 21:04:35 UTC
6b488d5 Tomas Vondra 03 July 2023, 16:16:58 UTC Remove expensive test of postgres_fdw batch inserts The test inserted 70k rows into a foreign table, in order to verify correct behavior with more than 65535 parameters, and was added in response to a bug report. However, this is rather expensive, especially when running the tests under valgrind, CLOBBER_CACHE_ALWAYS etc. It doesn't seem worth it to keep running the test, so remove it from all branches (14+). Backpatch-through: 14 Discussion: https://postgr.es/m/2131017.1623451468@sss.pgh.pa.us 03 July 2023, 16:35:19 UTC
1615270 Andrew Dunstan 03 July 2023, 14:06:26 UTC Improve pg_basebackup long file name test Windows robustness Creation of a file with a very long name can create problems on Windows due to its file path limits. Work around that by creating the file via a symlink with a shorter name. Error displayed by buildfarm animal fairywren.o Backpatch to all live branches 03 July 2023, 14:09:12 UTC
c24e9ef Michael Paquier 03 July 2023, 01:06:13 UTC Make PG_TEST_NOCLEAN work for temporary directories in TAP tests When set, this environment variable was only effective for data directories but not for all the other temporary files created by PostgreSQL::Test::Utils. Keeping the temporary files after a successful run can be useful for debugging purposes. The documentation is updated to reflect the new behavior, with contents available in doc/ since v16 and in src/test/perl/README since v15. Author: Jacob Champion Reviewed-by: Daniel Gustafsson Discussion: https://postgr.es/m/CAAWbhmgHtDH1SGZ+Fw05CsXtE0mzTmjbuUxLB9mY9iPKgM6cUw@mail.gmail.com Discussion: https://postgr.es/m/YyPd9unV14SX2bLF@paquier.xyz Backpatch-through: 11 03 July 2023, 01:06:13 UTC
76d5966 Thomas Munro 02 July 2023, 22:53:44 UTC Silence "missing contrecord" error. Commit dd38ff28ad added a new error message "missing contrecord" when we fail to reassemble a record. Unfortunately that caused noisy messages to be logged by pg_waldump at end of segment, and by walsender when asked to shut down on a segment boundary. Remove the new error message, so that this condition signals end-of- WAL without a message. It's arguably a reportable condition that should not be silenced while performing crash recovery, but fixing that without introducing noise in the other cases will require more research. Back-patch to 15. Reported-by: Tomas Vondra <tomas.vondra@enterprisedb.com> Discussion: https://postgr.es/m/6a1df56e-4656-b3ce-4b7a-a9cb41df8189%40enterprisedb.com 02 July 2023, 23:21:56 UTC
9cf8509 Tomas Vondra 02 July 2023, 18:29:01 UTC Fix oversight in handling of modifiedCols since f24523672d Commit f24523672d fixed a memory leak by moving the modifiedCols bitmap into the per-row memory context. In the case of AFTER UPDATE triggers, the bitmap is however referenced from an event kept until the end of the query, resulting in a use-after-free bug. Fixed by copying the bitmap into the AfterTriggerEvents memory context, which is the one where we keep the trigger events. There's only one place that needs to do the copy, but the memory context may not exist yet. Doing that in a separate function seems more readable. Report by Alexander Pyhalov, fix by me. Backpatch to 13, where the bitmap was added to the event by commit 71d60e2aa0. Reported-by: Alexander Pyhalov Backpatch-through: 13 Discussion: https://postgr.es/m/acddb17c89b0d6cb940eaeda18c08bbe@postgrespro.ru 02 July 2023, 20:22:31 UTC
9ae7b5d Tomas Vondra 02 July 2023, 16:54:09 UTC Fix memory leak in Incremental Sort rescans The Incremental Sort had a couple issues, resulting in leaking memory during rescans, possibly triggering OOM. The code had a couple of related flaws: 1. During rescans, the sort states were reset but then also set to NULL (despite the comment saying otherwise). ExecIncrementalSort then sees NULL and initializes a new sort state, leaking the memory used by the old one. 2. Initializing the sort state also automatically rebuilt the info about presorted keys, leaking the already initialized info. presorted_keys was also unnecessarily reset to NULL. Patch by James Coleman, based on patches by Laurenz Albe and Tom Lane. Backpatch to 13, where Incremental Sort was introduced. Author: James Coleman, Laurenz Albe, Tom Lane Reported-by: Laurenz Albe, Zu-Ming Jiang Backpatch-through: 13 Discussion: https://postgr.es/m/b2bd02dff61af15e3526293e2771f874cf2a3be7.camel%40cybertec.at Discussion: https://postgr.es/m/db03c582-086d-e7cd-d4a1-3bc722f81765%40inf.ethz.ch 02 July 2023, 18:04:16 UTC
cb5fd12 Noah Misch 01 July 2023, 17:00:39 UTC Fix test of pg_stat_io for wal_level=minimal. Back-patch to v16, which introduced the test. 01 July 2023, 17:00:42 UTC
c729642 Bruce Momjian 30 June 2023, 21:35:47 UTC doc: PG 16 relnotes, remove "Have initdb use ICU by default" Item reverted. Backpatch-through: 16 only 30 June 2023, 21:35:47 UTC
0a14bca Amit Langote 30 June 2023, 06:48:54 UTC Add a test case for a316a3bc a316a3bc fixed the code in build_simpl_rel() that propagates RelOptInfo.userid from parent to child rels so that it works correctly for the child rels of a UNION ALL subquery rel, though no tests were added in that commit. So do so here. As noted in the discussion, coming up with a test case in the core regression suite for this fix has turned out to be tricky, so the test case is added to the postgres_fdw's suite instead. postgresGetForeignRelSize()'s use of user mapping for the user specified in RelOptInfo.userid makes it relatively easier to craft a test case around. Discussion: https://postgr.es/m/CA%2BHiwqH91GaFNXcXbLAM9L%3DzBwUmSyv699Mtv3i1_xtk9Xec_A%40mail.gmail.com Backpatch-through: 16 30 June 2023, 06:48:54 UTC
f4691e2 Michael Paquier 30 June 2023, 04:54:53 UTC Fix marking of indisvalid for partitioned indexes at creation The logic that introduced partitioned indexes missed a few things when invalidating a partitioned index when these are created, still the code is written to handle recursions: 1) If created from scratch because a mapping index could not be found, the new index created could be itself invalid, if for example it was a partitioned index with one of its leaves invalid. 2) A CCI was missing when indisvalid is set for a parent index, leading to inconsistent trees when recursing across more than one level for a partitioned index creation if an invalidation of the parent was required. This could lead to the creation of a partition index tree where some of the partitioned indexes are marked as invalid, but some of the parents are marked valid, which is not something that should happen (as validatePartitionedIndex() defines, indisvalid is switched to true for a partitioned index iff all its partitions are themselves valid). This patch makes sure that indisvalid is set to false on a partitioned index if at least one of its partition is invalid. The flag is set to true if *all* its partitions are valid. The regression test added in this commit abuses of a failed concurrent index creation, marked as invalid, that maps with an index created on its partitioned table afterwards. Reported-by: Alexander Lakhin Reviewed-by: Alexander Lakhin Discussion: https://postgr.es/m/14987634-43c0-0cb3-e075-94d423607e08@gmail.com Backpatch-through: 11 30 June 2023, 04:54:53 UTC
871d342 Tom Lane 29 June 2023, 23:14:22 UTC Arm gen_node_support.pl's nodetag ABI stability check in v16. Per RELEASE_CHANGES checklist. 29 June 2023, 23:14:22 UTC
97d8910 Michael Paquier 29 June 2023, 22:49:01 UTC Fix pg_depend entry to AMs after ALTER TABLE .. SET ACCESS METHOD ALTER TABLE .. SET ACCESS METHOD was not registering a dependency to the new access method with the relation altered in its rewrite phase, making possible the drop of an access method even if there are relations that depend on it. During the rewrite, a temporary relation is created to build the new relation files before swapping the new and old files, and, while the temporary relation was registering a correct dependency to the new AM, the old relation did not do that. A dependency on the access method is added when the relation files are swapped, which is the point where pg_class is updated. Materialized views and tables use the same code path, hence both were impacted. Backpatch down to 15, where this command has been introduced. Reported-by: Alexander Lakhin Reviewed-by: Nathan Bossart, Andres Freund Discussion: https://postgr.es/m/18000-9145c25b1af475ca@postgresql.org Backpatch-through: 15 29 June 2023, 22:49:01 UTC
5f87a02 Andres Freund 29 June 2023, 16:12:52 UTC meson: Remove redundant return code check run_command(check: true) already would have errorred out before the check is reached. Author: Tristan Partin <tristan@neon.tech> Discussion: CSPIJVUDZFKX.3KHMOAVGF94RV@c3po 29 June 2023, 16:16:03 UTC
a798660 Tom Lane 29 June 2023, 16:12:52 UTC Defend against bogus parameterization of join input paths. An outer join cannot be formed using an input path that is parameterized by a value that is supposed to be nulled by the outer join. This is obviously nonsensical, and it could lead to a bad plan being selected; although currently it seems that we'll hit various sanity-check assertions first. I think that such cases were formerly prevented by the delay_upper_joins mechanism, but now that that's gone we need an explicit check. (Perhaps we should avoid generating baserel paths that could lead to this situation in the first place; but it seems like having a defense at the join level would be a good idea anyway.) Richard Guo and Tom Lane, per report from Jaime Casanova Discussion: https://postgr.es/m/CAJKUy5g2uZRrUDZJ8p-=giwcSHVUn0c9nmdxPSY0jF0Ov8VoEA@mail.gmail.com 29 June 2023, 16:12:52 UTC
43af714 Tom Lane 29 June 2023, 14:19:10 UTC Fix order of operations in ExecEvalFieldStoreDeForm(). If the given composite datum is toasted out-of-line, DatumGetHeapTupleHeader will perform database accesses to detoast it. That can invalidate the result of get_cached_rowtype, as documented (perhaps not plainly enough) in that function's API spec; which leads to strange errors or crashes when we try to use the TupleDesc to read the tuple. In short then, trying to update a field of a composite column could fail intermittently if the overall column value is wide enough to require toasting. We can fix the bug at no cost by just changing the order of operations, since we don't need the TupleDesc until after detoasting. (Other callers of get_cached_rowtype appear to get this right already, so there's only one bug.) Note that the added regression test case reveals this bug reliably only with debug_discard_caches/CLOBBER_CACHE_ALWAYS. Per bug #17994 from Alexander Lakhin. Sadly, this patch does not fix the missing-values issue revealed in the bug discussion; we'll need some more work to cover that. Discussion: https://postgr.es/m/17994-5c7100b51b4790e9@postgresql.org 29 June 2023, 14:19:10 UTC
b750e74 Peter Eisentraut 29 June 2023, 11:16:52 UTC meson: Fix intl misspelling Author: Tristan Partin <tristan@neon.tech> Discussion: https://www.postgresql.org/message-id/flat/CSPIJVUDZFKX.3KHMOAVGF94RV%40c3po 29 June 2023, 11:16:52 UTC
99e5766 Peter Eisentraut 29 June 2023, 11:06:41 UTC meson: Use a better error message in an impossible case Meson validates 'choice' options for us, so technically this case is impossible. A better error message helps people reading the code understand what is going on in that branch. Author: Tristan Partin <tristan@neon.tech> Discussion: https://www.postgresql.org/message-id/flat/CSPIJVUDZFKX.3KHMOAVGF94RV%40c3po 29 June 2023, 11:06:41 UTC
af492eb Peter Eisentraut 29 June 2023, 11:06:02 UTC meson: Make some Meson style more consistent with surrounding code Author: Tristan Partin <tristan@neon.tech> Discussion: https://www.postgresql.org/message-id/flat/CSPIJVUDZFKX.3KHMOAVGF94RV%40c3po 29 June 2023, 11:06:02 UTC
74668cb Peter Eisentraut 29 June 2023, 11:05:05 UTC meson: Fix some grammar usage in Meson comments Author: Tristan Partin <tristan@neon.tech> Discussion: https://www.postgresql.org/message-id/flat/CSPIJVUDZFKX.3KHMOAVGF94RV%40c3po 29 June 2023, 11:05:05 UTC
f5159c7 Peter Eisentraut 29 June 2023, 11:04:04 UTC meson: Mention the correct way to disable readline support Using false to disable a feature option is incorrect. Author: Tristan Partin <tristan@neon.tech> Discussion: https://www.postgresql.org/message-id/flat/CSPIJVUDZFKX.3KHMOAVGF94RV%40c3po 29 June 2023, 11:04:04 UTC
45c88ee Peter Eisentraut 29 June 2023, 11:03:19 UTC meson: Remove old comment That portion of code is not run in the Windows case already given the structure of the surrounding if statement. Author: Tristan Partin <tristan@neon.tech> Discussion: https://www.postgresql.org/message-id/flat/CSPIJVUDZFKX.3KHMOAVGF94RV%40c3po 29 June 2023, 11:03:19 UTC
38977dd Peter Eisentraut 29 June 2023, 10:56:30 UTC meson: Use the not_found_dep constant Previously in the build description, a not_found_dep was defined. Make use of it. Author: Tristan Partin <tristan@neon.tech> Discussion: https://www.postgresql.org/message-id/flat/CSPIJVUDZFKX.3KHMOAVGF94RV%40c3po 29 June 2023, 10:56:30 UTC
c55d31e Peter Eisentraut 29 June 2023, 10:53:41 UTC meson: Attach colon to keyword argument This matches the style found in the rest of the Meson build description. Author: Tristan Partin <tristan@neon.tech> Discussion: https://www.postgresql.org/message-id/flat/CSPIJVUDZFKX.3KHMOAVGF94RV%40c3po 29 June 2023, 10:53:41 UTC
b2ec7f5 Peter Eisentraut 29 June 2023, 10:52:12 UTC meson: Use consistent Meson option description formats Author: Tristan Partin <tristan@neon.tech> Discussion: https://www.postgresql.org/message-id/flat/CSPIJVUDZFKX.3KHMOAVGF94RV%40c3po 29 June 2023, 10:52:12 UTC
529449c Peter Eisentraut 29 June 2023, 10:47:33 UTC meson: Use consistent casing in Meson option descriptions Meson itself uses capital letters for option descriptions, so follow that. Author: Tristan Partin <tristan@neon.tech> Discussion: https://www.postgresql.org/message-id/flat/CSPIJVUDZFKX.3KHMOAVGF94RV%40c3po 29 June 2023, 10:47:33 UTC
559bdd5 Peter Eisentraut 29 June 2023, 10:44:27 UTC meson: Remove triple-quoted strings Triple-quoted strings are for multiline strings in Meson. None of the descriptions that got changed were multiline and the entire file uses single-line descriptions. Author: Tristan Partin <tristan@neon.tech> Discussion: https://www.postgresql.org/message-id/flat/CSPIJVUDZFKX.3KHMOAVGF94RV%40c3po 29 June 2023, 10:44:27 UTC
efcf55f Peter Eisentraut 29 June 2023, 08:30:55 UTC Remove inappropriate raw_expression_tree_walker() code It was walking into the ColumnDef->compression field, which is not a node but a string. This code is currently not reachable (because the compression field is only set in situations that don't go through raw_expression_tree_walker()), but if it had been, this could have behaved erratically. 29 June 2023, 08:34:53 UTC
39a584d Peter Eisentraut 29 June 2023, 07:14:55 UTC Error message wording improvements 29 June 2023, 07:14:55 UTC
dda9f8e Nathan Bossart 29 June 2023, 04:32:53 UTC Fix psql \?'s entries for \dp and \z. d913928c9c added support for the "S" modifier to psql's \dp and \z meta-commands, but it missed updating the corresponding entries in \?'s output. Author: Noriyoshi Shinoda Discussion: https://postgr.es/m/DM4PR84MB17342A51B3A1556CFBC7A4B2EE25A%40DM4PR84MB1734.NAMPRD84.PROD.OUTLOOK.COM 29 June 2023, 04:32:53 UTC
bc8e9a6 Michael Paquier 29 June 2023, 00:17:26 UTC pg_stat_statements: Fix second comment related to entry resets This should have been part of dc73db6, but it got lost in the mix. Oversight in 6b4d23f. Author: Japin Li Discussion: https://postgr.es/m/MEYP282MB1669FC91C764E277821936D3B624A@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM Backpatch-through: 14 29 June 2023, 00:17:26 UTC
dc73db6 Michael Paquier 28 June 2023, 23:04:47 UTC pg_stat_statements: Fix incorrect comment with entry resets Oversight in 6b4d23f. Author: Japin Li, Richard Guo Discussion: https://postgr.es/m/MEYP282MB1669FC91C764E277821936D3B624A@MEYP282MB1669.AUSP282.PROD.OUTLOOK.COM Backpatch-through: 14 28 June 2023, 23:04:47 UTC
046c8c5 Peter Eisentraut 28 June 2023, 17:30:26 UTC Reword error messages for consistency 28 June 2023, 17:30:26 UTC
ac1e974 Tom Lane 28 June 2023, 16:48:14 UTC Doc: minor wording adjustments in transaction isolation discussion. Re-word for more clarity, per gripe from Anton Sidyakin. Discussion: https://postgr.es/m/168745911769.2239590.6062411529242609290@wrigleys.postgresql.org 28 June 2023, 16:48:14 UTC
back to top