aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAge
...
* docs: Rework sections on partition pruning/exclusionAlvaro Herrera2018-05-12
| | | | | | | | | | | | | Explain partition pruning more thoroughly, in a section above the one that explains constraint exclusion, since the new feature is the one that will be used more extensively from now on. Move some of the material from the constraint exclusion subsection to the one on partition pruning, so that we can explain the legacy method by explaining the differences with the new one instead of repeating it. Author: David Rowley, Álvaro Herrera Reviewed-by: Amit Langote, David G. Johnston, Justin Pryzby Discussion: https://postgr.es/m/CAKJS1f8PECxEi1YQ9nhVtshtfOMHUzAMm_Zp4gGCOCnMPjEKJA@mail.gmail.com
* Doc: fix overenthusiastic markup.Tom Lane2018-05-11
| | | | | | | I get "WARNING: nested link may be undefined in output: <xref @linkend = 'pgbench'> nested inside parent element link" from this. Also remove some trailing whitespace.
* docs: more PG 11 markup and email suggestionsBruce Momjian2018-05-11
|
* doc: markup for PG 11 release notes and included email tipsBruce Momjian2018-05-11
|
* docs: initial draft of PG 11 release notesBruce Momjian2018-05-11
|
* docs: clarify that CREATE TABLE ... _AS_ can be parallelizedBruce Momjian2018-05-10
| | | | CREATE TABLE without AS doesn't have anything to parallelize.
* Various improvements of skipping index scan during vacuum technicsTeodor Sigaev2018-05-10
| | | | | | | | | | | | | | | | | - Change vacuum_cleanup_index_scale_factor GUC to PGC_USERSET. vacuum_cleanup_index_scale_factor GUC was defined as PGC_SIGHUP. But this GUC affects not only autovacuum. So it might be useful to change it from user session in order to influence manually runned VACUUM. - Add missing tab-complete support for vacuum_cleanup_index_scale_factor reloption. - Fix condition for B-tree index cleanup. Zero value of vacuum_cleanup_index_scale_factor means that user wants B-tree index cleanup to be never skipped. - Documentation and comment improvements Authors: Justin Pryzby, Alexander Korotkov, Liudmila Mantrova Reviewed by: all authors and Robert Haas Discussion: https://www.postgresql.org/message-id/flat/20180502023025.GD7631%40telsasoft.com
* doc: Restrictions on InitPlans in parallel queries relaxed.Robert Haas2018-05-09
| | | | | | | | | This updates the documentation for changes originally made in commit e89a71fb449af2ef74f47be1175f99956cf21524. Patch by me, reviewed (but not entirely endorsed) by Amit Kapila. Discussion: http://postgr.es/m/CA+Tgmoa+vupW8V_gBonz6hU7WwN2zJ=UTsVWCVB+rN6vaaXfZw@mail.gmail.com
* Update time zone data files to tzdata release 2018e.Tom Lane2018-05-09
| | | | | | | | | | | | | | | | | | | | | | | | | | DST law changes in North Korea. Redefinition of "daylight savings" in Ireland, as well as for some past years in Namibia and Czechoslovakia. Additional historical corrections for Czechoslovakia. With this change, the IANA database models Irish timekeeping as following "standard time" in summer, and "daylight savings" in winter, so that the daylight savings offset is one hour behind standard time not one hour ahead. This does not change their UTC offset (+1:00 in summer, 0:00 in winter) nor their timezone abbreviations (IST in summer, GMT in winter), though now "IST" is more correctly read as "Irish Standard Time" not "Irish Summer Time". However, the "is_dst" column in the pg_timezone_names view will now be true in winter and false in summer for the Europe/Dublin zone. Similar changes were made for Namibia between 1994 and 2017, and for Czechoslovakia between 1946 and 1947. So far as I can find, no Postgres internal logic cares about which way tm_isdst is reported; in particular, since commit b2cbced9e we do not rely on it to decide how to interpret ambiguous timestamps during DST transitions. So I don't think this change will affect any Postgres behavior other than the timezone-view outputs. Discussion: https://postgr.es/m/30996.1525445902@sss.pgh.pa.us
* pgstatindex, pageinspect: handle partitioned indexesAlvaro Herrera2018-05-09
| | | | | | | | | | | | | | Commit 8b08f7d4820f failed to update these modules to at least give non-broken error messages for partitioned indexes. Add appropriate error support to them. Peter G. was complaining about a problem of unfriendly error messages; while we haven't fixed that yet, subsequent discussion let to discovery of these unhandled cases. Author: Michaël Paquier Reported-by: Peter Geoghegan Discussion: https://postgr.es/m/CAH2-WzkOKptQiE51Bh4_xeEHhaBwHkZkGtKizrFMgEkfUuRRQg@mail.gmail.com
* pgstatindex: HASH -> hashAlvaro Herrera2018-05-09
| | | | | | | | | | | Fix the lone error message in the whole source tree to use capitalized HASH when referring to hash indexes, making it look like all the other messages. Someday it would be good to standardize 'B-Tree', 'B-tree', 'btree', and random other spellings, too, but that's a larger patch ... Author: Álvaro Herrera
* Add relkind 'I' to catalog.sgml's list relkindsAlvaro Herrera2018-05-09
| | | | | | | | Commit 8b08f7d4820f added a relkind for local partitioned indexes, but failed to add it to pg_class's list of possible relkinds. Repair. Author: Peter Geoghegan, Michaël Paquier Discussion: https://postgr.es/m/CAH2-WzkOKptQiE51Bh4_xeEHhaBwHkZkGtKizrFMgEkfUuRRQg@mail.gmail.com
* Fix assorted partition pruning bugsAlvaro Herrera2018-05-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | match_clause_to_partition_key failed to consider COERCION_PATH_ARRAYCOERCE cases in scalar-op-array expressions, so it was possible to crash the server easily. To handle this case properly (ie. prune partitions) we would need to run a bit of executor code during planning. Maybe it can be improved, but for now let's just not crash. Add a test case that used to trigger the crash. Author: Michaël Paquier match_clause_to_partition_key failed to indicate that operators that don't have a commutator in a btree opclass are unsupported. It is possible for this to cause a crash later if such an operator is used in a scalar-op-array expression. Add a test case that used to the crash. Author: Amit Langote One caller of gen_partprune_steps_internal in match_clause_to_partition_key was too optimistic about the former never returning an empty step list. Rid it of its innocence. (Having fixed the bug above, I no longer know how to exploit this, so no test case for it, but it remained a bug.) Revise code flow a little bit, for succintness. Author: Álvaro Herrera Reported-by: Marina Polyakova Reviewed-by: Michaël Paquier Reviewed-by: Amit Langote Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/ff8f9bfa485ff961d6bb43e54120485b@postgrespro.ru
* Restrict vertical tightness to parentheses in Perl codeAndrew Dunstan2018-05-09
| | | | | | | | | | | | | | | | | The vertical tightness settings collapse vertical whitespace between opening and closing brackets (parentheses, square brakets and braces). This can make data structures in particular harder to read, and is not very consistent with our style in non-Perl code. This patch restricts that setting to parentheses only, and reformats all the perl code accordingly. Not applying this to parentheses has some unfortunate effects, so the consensus is to keep the setting for parentheses and not for the others. The diff for this patch does highlight some places where structures should have trailing commas. They can be added manually, as there is no automatic tool to do so. Discussion: https://postgr.es/m/a2f2b87c-56be-c070-bfc0-36288b4b41c1@2ndQuadrant.com
* perltidy some recent code changes before changing perltidy settingsAndrew Dunstan2018-05-09
|
* Make gen_partprune_steps staticAlvaro Herrera2018-05-09
| | | | | | | | | | There's no need to export this function, so don't. Michaël didn't actually write the patch, but we list him as first author because with a trivial one like this, intellectual authorship is as important (if not more) as bit shovelling. Author: Michaël Paquier, Amit Langote Discussion: https://postgr.es/m/c91299c4-199b-0f16-339b-a29d6d2a39ee@lab.ntt.co.jp
* Remove useless 'default' clauseAlvaro Herrera2018-05-09
| | | | | | | | Author: Michael Paquier Reviewed-by: Amit Langote Reviewed-by: Álvaro Herrera Discussion: https://postgr.es/m/20180424012042.GD1570@paquier.xyz Discussion: https://postgr.es/m/20180509061039.GC11897@paquier.xyz
* Add a script and a config file to run perlcriticAndrew Dunstan2018-05-09
| | | | | | | | This is similar to what we do to run perltidy. For now we only run at severity level 5. Over time we can improve our perl code and reduce the severity level. Discussion: https://postgr.es/m/86aa2a3a-0c68-21fb-9560-84ad6914d561@2ndQuadrant.com
* Improve jsonb cast error messageTeodor Sigaev2018-05-09
| | | | | | | | Initial variant of error message didn't follow style of another casting error messages and wasn't informative. Per gripe from Robert Haas. Reviewer: Tom Lane Discussion: https://www.postgresql.org/message-id/flat/CA%2BTgmob08StTV9yu04D0idRFNMh%2BUoyKax5Otvrix7rEZC8rMw%40mail.gmail.com#CA+Tgmob08StTV9yu04D0idRFNMh+UoyKax5Otvrix7rEZC8rMw@mail.gmail.com
* Improve inefficient regexes in vacuumdb TAP test.Tom Lane2018-05-08
| | | | | | | | | | | | | | | | | | | | | | The regexes used in 102_vacuumdb_stages.pl to check the postmaster log for expected output contained several places with ".*.*", which is underdetermined and can cause exponential runtime growth in Perl's regex matcher (since it's not bright enough not to waste time seeing whether different splits of the same substring would allow a match). We were fortunate that the amount of text in the postmaster log was generally not enough to make the runtime go to the moon; although commit 6271fceb8 had been on the hairy edge of an obvious problem, thanks to its increasing the default log verbosity to DEBUG1. Experimentation shows that anyone who tried to run this test case with an even higher log verbosity would have been in for serious pain. But even at default logging level, fixing this saves several hundred ms on my workstation, more on slower buildfarm members. Remove the extra ".*"s, restoring more-or-less-linear matching speed. Back-patch to 9.4 where the test case was added, mostly in case anyone tries to do related debugging in a back branch. Discussion: https://postgr.es/m/32459.1525657786@sss.pgh.pa.us
* Improve initdb's query for generating default descriptions a little.Tom Lane2018-05-08
| | | | | | | | | | | | | | | | | | While poking into initdb's performance, I noticed that this query wasn't being done very intelligently. By forcing it to execute obj_description() for each pg_proc/pg_operator join row, we were essentially setting up a nestloop join to pg_description, which is not a bright query plan when there are hundreds of outer rows. Convert the check for a "deprecated" operator into a NOT EXISTS so that it can be done as a hashed antijoin. On my workstation this reduces the time for this query from ~ 35ms to ~ 10ms. Which is not a huge win, but it adds up over buildfarm runs. In passing, insert forced query breaks (\n\n, in single-user mode) after each SQL-query file that initdb sources, and after some relatively new queries in setup_privileges(). This doesn't make a lot of difference normally, but it will result in briefer, saner error messages if anything goes wrong.
* Refine error messagesPeter Eisentraut2018-05-08
| | | | "JSON" when not referring to a data type should be upper case.
* Count heap tuples in non-SnapshotAny path in IndexBuildHeapRangeScan().Tom Lane2018-05-08
| | | | | | | | | | | | | | | | | | | | | | Brown-paper-bag bug in commit 7c91a0364: when we rearranged the placement of "reltuples += 1" statements, we missed including one in this code path. The net effect of that was that CREATE INDEX CONCURRENTLY would set the table's pg_class.reltuples to zero, as would index builds done during bootstrap mode. (It seems like parallel index builds ought to fail similarly, but they don't, perhaps because reltuples is computed in some other way. You certainly couldn't figure that out from the abysmally underdocumented parallelism code in this area.) I was led to this by wondering why initdb seemed to have slowed down as a result of 7c91a0364, as is evident in the buildfarm's timing history. The reason is that every system catalog with indexes had pg_class.reltuples = 0 after bootstrap, causing the planner to make some terrible choices for queries in the post-bootstrap steps. On my workstation, this fix causes the runtime of "initdb -N" to drop from ~2.0 sec to ~1.4 sec, which is almost though not quite back to where it was in v10. That's not much of a deal for production use perhaps, but it makes a noticeable difference for buildfarm and "make check-world" runs, which do a lot of initdbs.
* Clean up some perlcritic warningsAndrew Dunstan2018-05-07
| | | | | | | | | In Catalog.pm, mark eval of a string instead of a block as allowed. Disallow perlcritic completely in Gen_dummy_probes.pl, as it's generated code. Protect a couple of lines in plperl code from perltidy, so that the annotation for perlcritic stays on the same line as the construct it would otherwise object to.
* Undo extra chattiness of postmaster logs in TAP tests.Tom Lane2018-05-07
| | | | | | | | | | Commit 6271fceb8 changed PostgresNode.pm to force log_min_messages = debug1 in all TAP tests, without any discussion and without a concrete need for it. This makes some of the TAP tests noticeably slower (although much of that may be due to poorly-written regexes), and for certain it's bloating the buildfarm logs. Revert the change. Discussion: https://postgr.es/m/32459.1525657786@sss.pgh.pa.us
* Update oidjoins regression test for v11.Tom Lane2018-05-07
| | | | | | | | | | | Commit 86f575948 already manually updated the oidjoins test for the new pg_constraint.conparentid => pg_constraint.oid relationship, but failed to update findoidjoins/README, thus the apparent inconsistency here. Michael Paquier Discussion: https://postgr.es/m/20180507001811.GA27389@paquier.xyz
* Suppress compiler warnings when building with --enable-dtrace.Tom Lane2018-05-07
| | | | | | | | | | | | Most versions of "dtrace -h" drop const qualifiers from the declarations of probe functions (though macOS gets it right). This causes compiler warnings when we pass in pointers to const. Repair by extending our existing post-processing of the probes.h file. To do so, assume that all "char *" arguments should be "const char *"; that seems reasonably safe. Thomas Munro Discussion: https://postgr.es/m/CAEepm=2j1pWSruQJqJ91ZDzD8w9ZZDsM4j2C6x75C-VryWg-_w@mail.gmail.com
* Last-minute updates for release notes.Tom Lane2018-05-07
| | | | | | The set of functions that need parallel-safety adjustments isn't the same in 9.6 as 10, so I shouldn't have blindly back-patched that list. Adjust as needed. Also, provide examples of the commands to issue.
* Last-minute updates for release notes.Tom Lane2018-05-07
| | | | Security: CVE-2018-1115
* doc: Improve spelling and wording a bitPeter Eisentraut2018-05-07
|
* doc: Fix minor markup issuePeter Eisentraut2018-05-07
| | | | | | | There shouldn't be a line break between two adjacent tags, because that will appear as whitespace in the output. (The rendering engine might in turn collapse that whitespace away, so it might not actually make a difference, but it's more correct this way.)
* adminpack: Revoke EXECUTE on pg_logfile_rotate()Stephen Frost2018-05-07
| | | | | | | | | | | | | | | | | | | | | | In 9.6, we moved a number of functions over to using the GRANT system to control access instead of having hard-coded superuser checks. As it turns out, adminpack was creating another function in the catalog for one of those backend functions where the superuser check was removed, specifically pg_rotate_logfile(), but it didn't get the memo about having to REVOKE EXECUTE on the alternative-name function (pg_logfile_rotate()), meaning that in any installations with adminpack on 9.6 and higher, any user is able to run the pg_logfile_rotate() function, which then calls pg_rotate_logfile() and rotates the logfile. Fix by adding a new version of adminpack (1.1) which handles the REVOKE. As this function should have only been available to the superuser, this is a security issue, albeit a minor one. In HEAD, move the changes implemented for adminpack up to be adminpack 2.0 instead of 1.1. Security: CVE-2018-1115
* Documentation updates for partitioning.Robert Haas2018-05-07
| | | | | | Takayuki Tsunakawa Discussion: http://postgr.es/m/0A3221C70F24FB45833433255569204D1F965627@G01JPEXMBYT05
* Remove unused macroPeter Eisentraut2018-05-06
| | | | left behind by db3af9feb19f39827e916145f88fa5eca3130cb2
* Release notes for 10.4, 9.6.9, 9.5.13, 9.4.18, 9.3.23.Tom Lane2018-05-06
|
* Clear severity 5 perlcritic warnings from vcregress.plAndrew Dunstan2018-05-06
| | | | | | My recent update for python3 support used some idioms that are unapproved. This fixes them. Backpatch to all live branches like the original.
* Fix bootstrap parser so that its keywords are unreserved words.Tom Lane2018-05-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | Mark Dilger pointed out that the bootstrap parser does not allow any of its keywords to appear as column values unless they're quoted, and proposed dealing with that by quoting such values in genbki.pl. Looking closer, though, we also have that problem with respect to table, column, and type names appearing in the .bki file: the parser would fail if any of those matched any of its keywords. While so far there have been no conflicts (that I've heard of), this seems like a booby trap waiting to catch somebody. Rather than clutter genbki.pl with enough quoting logic to handle all that, let's make the bootstrap parser grow up a little bit and treat its keywords as unreserved. Experimentation shows that it's fairly easy to do so with the exception of _null_, which I don't have a big problem with keeping as a reserved word. The only change needed is that we can't have the "close" command take an optional table name: it has to either require or forbid the table name to avoid shift/reduce conflicts. genbki.pl has historically always included the table name, so I took that option. The implementation has bootscanner.l passing forward the string value of each keyword, in case bootparse.y needs that. This avoids needing to know the precise spelling of each keyword in bootparse.y, which is good because that's not always obvious from the token name. Discussion: https://postgr.es/m/3024FC91-DB6D-4732-B31C-DF772DF039A0@gmail.com
* Revert "Test conversion of NaN between float4 and float8."Tom Lane2018-05-05
| | | | | | | | | This reverts commit 55e0e458170c76c1a0074cd550a13ec47e38a3fa. It's served its purpose of demonstrating what was wrong on buildfarm member opossum. We could consider putting some kind of single-purpose hack into ftod() to make the test pass there; but I don't think it's worth the trouble, since there are surely many other places whether this platform bug could manifest.
* Put in_range_float4_float8's work in-line.Tom Lane2018-05-05
| | | | | | | | | | | | | | | | | | | In commit 8b29e88cd, I'd dithered about whether to make in_range_float4_float8 be a standalone copy of the float in-range logic or have it punt to in_range_float8_float8. I went with the latter, which saves code space though at the cost of performance and readability. However, it emerges that this tickles a compiler or hardware bug on buildfarm member opossum. Test results from commit 55e0e4581 show conclusively that widening a float4 NaN to float8 produces Inf, not NaN, on that machine; which accounts perfectly for the window RANGE test failures it's been showing. We can dodge this problem by making in_range_float4_float8 be an independent function, so that it checks for NaN inputs before widening them. Ordinarily I'd not be very excited about working around such obviously broken functionality; but given that this was a judgment call to begin with, I don't mind reversing it.
* Remove extra newlines after PQerrorMessage()Peter Eisentraut2018-05-05
|
* First-draft release notes for 10.4.Tom Lane2018-05-04
| | | | | As usual, the release notes for other branches will be made by cutting these down, but put them up for community review first.
* Fix scenario where streaming standby gets stuck at a continuation record.Heikki Linnakangas2018-05-05
| | | | | | | | | | | | | | | | | | | | | If a continuation record is split so that its first half has already been removed from the master, and is only present in pg_wal, and there is a recycled WAL segment in the standby server that looks like it would contain the second half, recovery would get stuck. The code in XLogPageRead() incorrectly started streaming at the beginning of the WAL record, even if we had already read the first page. Backpatch to 9.4. In principle, older versions have the same problem, but without replication slots, there was no straightforward mechanism to prevent the master from recycling old WAL that was still needed by standby. Without such a mechanism, I think it's reasonable to assume that there's enough slack in how many old segments are kept around to not run into this, or you have a WAL archive. Reported by Jonathon Nelson. Analysis and patch by Kyotaro HORIGUCHI, with some extra comments by me. Discussion: https://www.postgresql.org/message-id/CACJqAM3xVz0JY1XFDKPP%2BJoJAjoGx%3DGNuOAshEDWCext7BFvCQ%40mail.gmail.com
* Don't mark pages all-visible spuriouslyAlvaro Herrera2018-05-04
| | | | | | | | | | | | | | | | | | | | | | | | | Dan Wood diagnosed a long-standing problem that pages containing tuples that are locked by multixacts containing live lockers may spuriously end up as candidates for getting their all-visible flag set. This has the long-term effect that multixacts remain unfrozen; this may previously pass undetected, but since commit XYZ it would be reported as "ERROR: found multixact 134100944 from before relminmxid 192042633" because when a later vacuum tries to freeze the page it detects that a multixact that should have gotten frozen, wasn't. Dan proposed a (correct) patch that simply sets a variable to its correct value, after a bogus initialization. But, per discussion, it seems better coding to avoid the bogus initializations altogether, since they could give rise to more bugs later. Therefore this fix rewrites the logic a little bit to avoid depending on the bogus initializations. This bug was part of a family introduced in 9.6 by commit a892234f830e; later, commit 38e9f90a227d fixed most of them, but this one was unnoticed. Authors: Dan Wood, Pavan Deolasee, Álvaro Herrera Reviewed-by: Masahiko Sawada, Pavan Deolasee, Álvaro Herrera Discussion: https://postgr.es/m/84EBAC55-F06D-4FBE-A3F3-8BDA093CE3E3@amazon.com
* Provide for testing on python3 modules when under MSVCAndrew Dunstan2018-05-04
| | | | | | | | | | | This should have been done some years ago as promised in commit c4dcdd0c2. However, better late than never. Along the way do a little housekeeping, including using a simpler test for the python version being tested, and removing a redundant subroutine parameter. These changes only apply back to release 9.5. Backpatch to all live releases.
* Allow MSYS as well as MINGW in Msys unameAndrew Dunstan2018-05-04
| | | | | | | Msys2's uname -s outputs a string beginning MSYS rather than MINGW as is output by Msys. Allow either in pg_upgrade's test.sh. Backpatch to all live branches.
* Sync our copy of the timezone library with IANA release tzcode2018e.Tom Lane2018-05-04
| | | | | | | | | | | The non-cosmetic changes involve teaching the "zic" tzdata compiler about negative DST. While I'm not currently intending that we start using negative-DST data right away, it seems possible that somebody would try to use our copy of zic with bleeding-edge IANA data. So we'd better be out in front of this change code-wise, even though it doesn't matter for the data file we're shipping. Discussion: https://postgr.es/m/30996.1525445902@sss.pgh.pa.us
* Fix precedence problem in new Perl code.Tom Lane2018-05-04
| | | | I think this bit of commit 1f1cd9b5d didn't do quite what I meant :-(
* pg_dump: Use current_database() instead of PQdb()Peter Eisentraut2018-05-04
| | | | | | | For querying pg_database about information about the database being dumped, look up by using current_database() instead of the value obtained from PQdb(). When using a connection proxy, the value from PQdb() might not be the real name of the database.
* Don't truncate away non-key attributes for leftmost downlinks.Teodor Sigaev2018-05-04
| | | | | | | | | | | | nbtsort.c does not need to truncate away non-key attributes for the minimum key of the leftmost page on a level, since this is only used to build a minus infinity downlink for the level's leftmost page. Truncating away non-key attributes in advance of truncating away all attributes in _bt_sortaddtup() does not affect the correctness of CREATE INDEX, but it is misleading. Author: Peter Geoghegan Discussion: https://www.postgresql.org/message-id/CAH2-WzkAS2M3ussHG-s_Av=Zo6dPjOxyu5fNRkYnxQV+YzGQ4w@mail.gmail.com
* Re-think predicate locking on GIN indexes.Teodor Sigaev2018-05-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The principle behind the locking was not very well thought-out, and not documented. Add a section in the README to explain how it's supposed to work, and change the code so that it actually works that way. This fixes two bugs: 1. If fast update was turned on concurrently, subsequent inserts to the pending list would not conflict with predicate locks that were acquired earlier, on entry pages. The included 'predicate-gin-fastupdate' test demonstrates that. To fix, make all scans acquire a predicate lock on the metapage. That lock represents a scan of the pending list, whether or not there is a pending list at the moment. Forget about the optimization to skip locking/checking for locks, when fastupdate=off. 2. If a scan finds no match, it still needs to lock the entry page. The point of predicate locks is to lock the gabs between values, whether or not there is a match. The included 'predicate-gin-nomatch' test tests that case. In addition to those two bug fixes, this removes some unnecessary locking, following the principle laid out in the README. Because all items in a posting tree have the same key value, a lock on the posting tree root is enough to cover all the items. (With a very large posting tree, it would possibly be better to lock the posting tree leaf pages instead, so that a "skip scan" with a query like "A & B", you could avoid unnecessary conflict if a new tuple is inserted with A but !B. But let's keep this simple.) Also, some spelling fixes. Author: Heikki Linnakangas with some editorization by me Review: Andrey Borodin, Alexander Korotkov Discussion: https://www.postgresql.org/message-id/0b3ad2c2-2692-62a9-3a04-5724f2af9114@iki.fi
generated by cgit v1.2.3 (git 2.25.1) at 2025-08-04 12:50:20 +0000