Commit
d2086b08b02 removed almost all cases where nbtree must release a
read buffer lock and acquire a write buffer lock instead, so remaining
cases in which that's still necessary are not notable enough to appear
in the nbtree README.
More importantly, holding on to a buffer pin in cases where nbtree must
trade a read lock for a write lock is very unlikely to save any I/O.
This seems to have been a long overlooked throwback to a time when
nbtree cared about write-ordering dependencies, and performed
synchronous buffer writes. It hasn't worked that way in many years.
among backends. As a result, we do page-level read locking on btree
pages in order to guarantee that no record is modified while we are
examining it. This reduces concurrency but guarantees correct
-behavior. An advantage is that when trading in a read lock for a
-write lock, we need not re-read the page after getting the write lock.
-Since we're also holding a pin on the shared buffer containing the
-page, we know that buffer still contains the page and is up-to-date.
+behavior.
We support the notion of an ordered "scan" of an index as well as
insertions, deletions, and simple lookups. A scan in the forward