From 68ef887842ff716097bbb1bad86a40bb62247061 Mon Sep 17 00:00:00 2001 From: Peter Geoghegan Date: Tue, 13 Aug 2019 17:16:44 -0700 Subject: [PATCH] Remove obsolete nbtree README commentary. 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. --- src/backend/access/nbtree/README | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/src/backend/access/nbtree/README b/src/backend/access/nbtree/README index 3d01b7854df..dce8bc98e93 100644 --- a/src/backend/access/nbtree/README +++ b/src/backend/access/nbtree/README @@ -65,10 +65,7 @@ copies of tree pages are unshared. Postgres shares in-memory buffers 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 -- 2.39.5