aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
* ExtendBufferedWhat -> BufferManagerRelation.Thomas Munro2023-08-23
| | | | | | | | | | | | | | | | | 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
* doc: PG 16 relnotes: properly indent and word-wrap textBruce Momjian2023-08-22
| | | | Backpatch-through: 16 only
* Fix pg_dump assertion failure when dumping pg_catalog.Jeff Davis2023-08-22
| | | | | | | | | | 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
* Cache by-reference missing values in a long lived contextAndrew Dunstan2023-08-22
| | | | | | | | | | | | | | | | 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
* doc: PG 16 relnotes: separate out psql \drg itemBruce Momjian2023-08-22
| | | | | | | | Reported-by: Pavel Luzanov Discussion: https://postgr.es/m/29b97504-80a3-fdcc-538e-cadde3d8ecd5@postgrespro.ru Backpatch-through: 16 only
* Add list of acknowledgments to release notesPeter Eisentraut2023-08-22
| | | | | | | This contains all individuals mentioned in the commit messages during PostgreSQL 16 development. current through REL_16_BETA3
* doc: PG 16 relnotes: adjust RANGE/ROWS window itemBruce Momjian2023-08-21
| | | | | | | | Reported-by: Erwin Brandstetter Discussion: https://postgr.es/m/CAGHENJ5Cj3wBH07YM5Lw2h5q8s65cNg_NEdkkWvmRo+vOormWw@mail.gmail.com Backpatch-through: 16 only
* doc: PG 16 relnotes: move role INHERIT item and clarify itBruce Momjian2023-08-21
| | | | | | | | | | 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
* Fix pg_stat_reset_single_table_counters() for shared relationsMichael Paquier2023-08-21
| | | | | | | | | | | | 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
* ci: macos: use cached macports installAndres Freund2023-08-19
| | | | | | | | | | | | | | | | | | | | | | 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
* Remove dubious warning message from SQL/JSON functionsPeter Eisentraut2023-08-18
| | | | | | | | | 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
* Invalidate smgr_targblock in smgrrelease().Thomas Munro2023-08-17
| | | | | | | | | | 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
* doc: PG 16 relnotes, add links to doc sectionsBruce Momjian2023-08-16
| | | | Backpatch-through: 16 only
* doc: PG 16 relnotes, initial markupBruce Momjian2023-08-16
| | | | | | Still need to add links to doc sections. Backpatch-through: 16 only
* Unify some error messagesPeter Eisentraut2023-08-16
| | | | | We had essentially the same error in several different wordings. Unify that.
* Improved CREATE SUBSCRIPTION message for clarityPeter Eisentraut2023-08-16
| | | | Discussion: https://www.postgresql.org/message-id/CAHut+PtfzQ7JRkb0-Y_UejAxaLQ17-bGMvV4MJJHcPoP3ML2bg@mail.gmail.com
* doc: PG 16 relnotes, update "current as of" dateBruce Momjian2023-08-15
| | | | Backpatch-through: 16 only
* De-pessimize ConditionVariableCancelSleep().Thomas Munro2023-08-15
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* doc: PG 16 relnotes: udpate for commits since branchingBruce Momjian2023-08-14
| | | | Backpatch-through: 16 only
* hio: Take number of prior relation extensions into accountAndres Freund2023-08-14
| | | | | | | | | | | | | | | | | | | | | | | | 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
* ci: macos: Remove use of -Dsegsize_blocks=6Andres Freund2023-08-12
| | | | | | | | | | | | | | | | | | 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
* ci: macos: Remove use of -DRANDOMIZE_ALLOCATED_MEMORYAndres Freund2023-08-12
| | | | | | | | | | | | | | | 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
* Fix off-by-one in XLogRecordMaxSize check.Noah Misch2023-08-12
| | | | | | | | | 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.
* Remove test from commit fa2e874946.Jeff Davis2023-08-10
| | | | | | | | | 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
* Document RelationGetIndexAttrBitmap betterAlvaro Herrera2023-08-10
| | | | | | | | | | | | 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>
* doc: PG 16 relnotes, mark current as of 2023-08-09Bruce Momjian2023-08-09
| | | | Backpatch-through: 16 only
* doc: PG 16 relnotes, move createuser and SCM itemsBruce Momjian2023-08-09
| | | | | | | | Reported-by: Noah Misch Discussion: https://postgr.es/m/20230805230847.GA1370050@rfd.leadboat.com Backpatch-through: 16 only
* doc: PG 16 relnotes, small wording improvementBruce Momjian2023-08-09
| | | | Backpatch-through: 16 only
* doc: PG 16 relnotes, merge and adjust CREATEROLE itemsBruce Momjian2023-08-09
| | | | | | | | Reported-by: Noah Misch Discussion: https://postgr.es/m/20230805230847.GA1370050@rfd.leadboat.com Backpatch-through: 16 only
* doc: PG 16 relnotes, add Windows 10 huge pages fixBruce Momjian2023-08-09
| | | | | | | | Reported-by: Michael Paquier Discussion: https://postgr.es/m/ZL0M28/L+grYR8o7@paquier.xyz Backpatch-through: 16 only
* Recalculate search_path after ALTER ROLE.Jeff Davis2023-08-09
| | | | | | | | | 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
* doc: PG 16 relnotes, fix various typosBruce Momjian2023-08-09
| | | | | | | | Reported-by: Erik Rijkers Discussion: https://postgr.es/m/9c83328b-c0ff-070f-f2be-c3dce484e182@xs4all.nl Backpatch-through: 16 only
* doc: PG 16 relnotes, adjust \ef+ body comment to mention \sfBruce Momjian2023-08-09
| | | | | | | | Reported-by: Laurenz Albe Discussion: https://postgr.es/m/99d731a543501eb31bf7b8db43d231a037d7cc80.camel@cybertec.at Backpatch-through: 16 only
* doc: PG 16 relnotes, remove MAINTAIN itemBruce Momjian2023-08-09
| | | | | | | | Feature was removed by commit 957445996f. Discussion: 957445996f Backpatch-through: 16
* Stamp 16beta3.REL_16_BETA3Tom Lane2023-08-07
|
* Reject substituting extension schemas or owners matching ["$'\].Noah Misch2023-08-07
| | | | | | | | | | | | | | | | | | | 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
* Translation updatesPeter Eisentraut2023-08-07
| | | | | Source-Git-URL: https://git.postgresql.org/git/pgtranslation/messages.git Source-Git-Hash: 97398d714ace69f0c919984e160f429b6fd2300e
* Don't Memoize lateral joins with volatile join conditionsDavid Rowley2023-08-07
| | | | | | | | | | | | | | | | | | 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
* Fix RLS policy usage in MERGE.Dean Rasheed2023-08-07
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Doc: update documentation for creating custom scan paths.Etsuro Fujita2023-08-03
| | | | | | | | | 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
* Update comments on CustomPath struct.Etsuro Fujita2023-08-03
| | | | | | | | | 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
* Fix ReorderBufferCheckMemoryLimit() comment.Masahiko Sawada2023-08-02
| | | | | | | | | | 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
* Fix pg_stat_io buffer reuse test instabilityAndres Freund2023-08-01
| | | | | | | | | | | | | | | | | | 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
* Fix performance regression in pg_strtointNN_safe functionsDavid Rowley2023-08-02
| | | | | | | | | | | | | | | | | | | | | 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
* Fix overly strict Assert in jsonpath codeDavid Rowley2023-08-02
| | | | | | | | | | | | | 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.
* Disallow replacing joins with scans in problematic cases.Etsuro Fujita2023-07-28
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Eliminate fixed token-length limit in hba.c.Tom Lane2023-07-27
| | | | | | | | | | | | | | | | | | | 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
* Fix performance problem with new COPY DEFAULT codeDavid Rowley2023-07-27
| | | | | | | | | | | | | | | | 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.
* Fix crash with RemoveFromWaitQueue() when detecting a deadlock.Masahiko Sawada2023-07-26
| | | | | | | | | | | | | | | | | | 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
* Remove unnecessary checks for indexes for REPLICA IDENTITY FULL tables.Masahiko Sawada2023-07-25
| | | | | | | | | | | | | | | | | | | | | | 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
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-03 04:43:55 +0000