From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fix pg_buffercache document |
Date: | 2020-05-07 09:12:16 |
Message-ID: | CAA4eK1JH7EXR5M7CKYbjoOoygAUGyt7cfkKC89C=rYo-guZyNA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 7, 2020 at 2:23 PM Masahiko Sawada
<masahiko(dot)sawada(at)2ndquadrant(dot)com> wrote:
>
> Hi,
>
> The following description in pg_buffercace is no longer true.
>
> When the pg_buffercache 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.
>
> We changed pg_buffercache_page so that it doesn't take buffer manager
> locks in commit 6e654546fb6. Therefore from version 10,
> pg_buffercache_page has less impact on normal buffer activity less but
> might not return a consistent snapshot across all buffers instead.
>
+1.
There is a typo in the patch (queris/queries). How about if slightly
reword it as "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."?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Marc Rechté | 2020-05-07 09:12:56 | min_wal_size > max_wal_size is accepted |
Previous Message | Amit Kapila | 2020-05-07 08:57:00 | Re: Back-patch is necessary? Re: Don't try fetching future segment of a TLI. |