On Thu, May 7, 2020 at 2:53 PM Masahiko Sawada <masahiko.saw...@2ndquadrant.com> wrote: > > On Thu, 7 May 2020 at 18:12, Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > On Thu, May 7, 2020 at 2:23 PM Masahiko Sawada > > <masahiko.saw...@2ndquadrant.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."? > > Thank you for your idea. Agreed. > > Attached the updated version patch. >
LGTM. I will commit this tomorrow unless there are more comments. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
