This is the main PostgreSQL git repository. http://git.postgresql.org/cgit/postgresql.git/atom?h=master 2018-05-04T08:27:50Z 2018-05-04T08:27:50Z Teodor Sigaev 2018-05-04T08:27:50Z urn:sha1:0bef1c0678d94436f80450d562a866bb6fa5e509 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 2018-04-07T13:59:14Z Teodor Sigaev 2018-04-07T13:59:14Z urn:sha1:b508a56f2f3a2d850e75a14661943d6b4dde8274 Hash index searches acquire predicate locks on the primary page of a bucket. It acquires a lock on both the old and new buckets for scans that happen concurrently with page splits. During a bucket split, a predicate lock is copied from the primary page of an old bucket to the primary page of a new bucket. Author: Shubham Barai, Amit Kapila Reviewed by: Amit Kapila, Alexander Korotkov, Thomas Munro Discussion: https://www.postgresql.org/message-id/flat/CALxAEPvNsM2GTiXdRgaaZ1Pjd1bs+sxfFsf7Ytr+iq+5JJoYXA@mail.gmail.com 2018-03-30T11:23:17Z Teodor Sigaev 2018-03-30T11:23:17Z urn:sha1:43d1ed60fdd96027f044e152176c0d45cd6bf443 Predicate locks are used on per page basis only if fastupdate = off, in opposite case predicate lock on pending list will effectively lock whole index, to reduce locking overhead, just lock a relation. Entry and posting trees are essentially B-tree, so locks are acquired on leaf pages only. Author: Shubham Barai with some editorization by me and Dmitry Ivanov Review by: Alexander Korotkov, Dmitry Ivanov, Fedor Sigaev Discussion: https://www.postgresql.org/message-id/flat/CALxAEPt5sWW+EwTaKUGFL5_XFcZ0MuGBcyJ70oqbWqr42YKR8Q@mail.gmail.com 2018-03-27T12:43:19Z Teodor Sigaev 2018-03-27T12:43:19Z urn:sha1:3ad55863e9392bff73377911ebbf9760027ed405 Add page-level predicate locking, due to gist's code organization, patch seems close to trivial: add check before page changing, add predicate lock before page scanning. Although choosing right place to check is not simple: it should not be called during index build, it should support insertion of new downlink and so on. Author: Shubham Barai with editorization by me and Alexander Korotkov Reviewed by: Alexander Korotkov, Andrey Borodin, me Discussion: https://www.postgresql.org/message-id/flat/CALxAEPtdcANpw5ePU3LvnTP8HCENFw6wygupQAyNBgD-sG3h0g@mail.gmail.com 2011-06-29T06:28:46Z Peter Eisentraut 2011-06-29T06:26:14Z urn:sha1:21f1e15aafb13ab2430e831a3da7d4d4f525d1ce We had previously (af26857a2775e7ceb0916155e931008c2116632f) established the U.S. spellings as standard. 2011-06-21T22:01:22Z Tom Lane 2011-06-21T22:00:09Z urn:sha1:a3290f655e12f43943bdabc9fd91477316af24a7 Fix some grammatical issues, try to clarify a couple of proofs, make the terminology more consistent. 2011-06-16T18:20:39Z Heikki Linnakangas 2011-06-16T18:12:56Z urn:sha1:78475b0ecac4e7793366d2dba0cb875a8fde6bb0 SSI is based on, as well as the optimizations about relative commit times and read-only transactions. Plus a bunch of other misc fixes and improvements. Dan Ports 2011-06-10T14:22:46Z Heikki Linnakangas 2011-06-10T14:22:00Z urn:sha1:c79c570bd8fbd6f074b8c186dfb08a9f4e3907e0 2011-05-31T20:11:46Z Peter Eisentraut 2011-05-31T20:10:05Z urn:sha1:ba4cacf0756f71e175d25bac78834715a353e64e For consistency, have all non-ASCII characters from contributors' names in the source be in UTF-8. But remove some other more gratuitous uses of non-ASCII characters. 2011-05-30T17:47:17Z Heikki Linnakangas 2011-05-30T17:42:16Z urn:sha1:3103f9a77d005f9d8b8ef492298bbbbf6c4b843f On further analysis, it turns out that it is not needed to duplicate predicate locks to the new row version at update, the lock on the version that the transaction saw as visible is enough. However, there was a different bug in the code that checks for dangerous structures when a new rw-conflict happens. Fix that bug, and remove all the row-version chaining related code. Kevin Grittner & Dan Ports, with some comment editorialization by me.