Thread: Fix pg_buffercache document
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. I've attached a patch to fix the documentation. Regards, -- Masahiko Sawada http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
On Thu, May 7, 2020 at 2:23 PM Masahiko Sawada <masahiko.sawada@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."? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
On Thu, 7 May 2020 at 18:12, Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Thu, May 7, 2020 at 2:23 PM Masahiko Sawada > <masahiko.sawada@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. Regards, -- Masahiko Sawada http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment
On Thu, May 7, 2020 at 2:53 PM Masahiko Sawada <masahiko.sawada@2ndquadrant.com> wrote: > > On Thu, 7 May 2020 at 18:12, Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > On Thu, May 7, 2020 at 2:23 PM Masahiko Sawada > > <masahiko.sawada@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
On Thu, May 7, 2020 at 4:02 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Thu, May 7, 2020 at 2:53 PM Masahiko Sawada > <masahiko.sawada@2ndquadrant.com> wrote: > > > > > > > > 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. > Pushed. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
On Fri, 8 May 2020 at 13:36, Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Thu, May 7, 2020 at 4:02 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > On Thu, May 7, 2020 at 2:53 PM Masahiko Sawada > > <masahiko.sawada@2ndquadrant.com> wrote: > > > > > > > > > > > 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. > > > > Pushed. > Thank you! Regards, -- Masahiko Sawada http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services