Fix inconsistency in pg_buffercache docs.

Commit 6e654546fb avoids locking bufmgr partitions to make pg_buffercache
less disruptive on production systems but forgot to update the docs.

Reported-by: Sawada Masahiko
Author: Sawada Masahiko
Reviewed-by: Amit Kapila
Backpatch-through: 10
Discussion: https://postgr.es/m/CA+fd4k6sD8oeP1qJbFAor=rCpYckU9DsywHiYx3x5Hz5Z8Ua_w@mail.gmail.com

diff --git a/doc/src/sgml/pgbuffercache.sgml b/doc/src/sgml/pgbuffercache.sgml
index fd2446d6542ed00c41bec4956efee32070368a0d..b2b5bce480c77a8a360f3de379fd1a591608b29b 100644 (file)
--- a/doc/src/sgml/pgbuffercache.sgml
+++ b/doc/src/sgml/pgbuffercache.sgml
@@ -135,12 +135,11 @@
   </para>
 
   <para>
-   When the <structname>pg_buffercache</structname> view is accessed, internal buffer
-   manager locks are taken for long enough to copy all the buffer state
-   data that the view will display.
-   This ensures that the view produces a consistent set of results, while not
-   blocking normal buffer activity longer than necessary.  Nonetheless there
-   could be some impact on database performance if this view is read often.
+   Since buffer manager locks are not taken to copy the buffer state data that
+   the view will display, accessing <structname>pg_buffercache</structname> view
+   has less impact on normal buffer activity but it doesn't provide a consistent
+   set of results across all buffers.  However, we ensure that the information of
+   each buffer is self-consistent.
   </para>
  </sect2>