MIME-Version: 1.0
References: <CALfch19pW48ZwWzUoRSpsaV9hqt0UPyaBPC4bOZ4W+c7FF566A@mail.gmail.com>
 <CAMm1aWbk-0C460G9ooy2yNSy1riecqvw4F7jPnqvToFZ_s4oGw@mail.gmail.com>
In-Reply-To: <CAMm1aWbk-0C460G9ooy2yNSy1riecqvw4F7jPnqvToFZ_s4oGw@mail.gmail.com>
From: Palak Chaturvedi <chaturvedipalak1911@gmail.com>
Date: Tue, 11 Jul 2023 18:08:56 +0530
Message-ID: <CALfch1890bL5SddyOpZDC8d-jZFOUGCGbOr+_11jLTwwJ_WEOA@mail.gmail.com>
Subject: Re: Extension Enhancement: Buffer Invalidation in pg_buffercache
To: Nitin Jadhav <nitinjadhavpostgres@gmail.com>, pgsql-hackers@postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CALfch1890bL5SddyOpZDC8d-jZFOUGCGbOr%2B_11jLTwwJ_WEOA%40mail.gmail.com>
Precedence: bulk

Hey Nitin,
>Will
>there be a scenario where the buffer is dirty and its reference count
>is zero?
There might be a buffer that has been dirtied but is not pinned or
being used currently by a process. So checking the refcount and then
dirty buffers helps.
>First, The TryInvalidateBuffer() tries to flush the buffer if it is
dirty and then tries to invalidate it if it meets the requirement.
Instead of directly doing this can we provide an option to the caller
to mention whether to invalidate the dirty buffers or not.
Yes that can be implemented with a default value of force. Will
implement it in the next patch.

On Wed, 5 Jul 2023 at 17:53, Nitin Jadhav <nitinjadhavpostgres@gmail.com> w=
rote:
>
> +1 for the idea. It's going to be more useful to test and understand
> the buffer management of PostgreSQL and it can be used to explicitly
> free up the buffers if there are any such requirements.
>
> I had a quick look over the patch. Following are the comments.
>
> First, The TryInvalidateBuffer() tries to flush the buffer if it is
> dirty and then tries to invalidate it if it meets the requirement.
> Instead of directly doing this can we provide an option to the caller
> to mention whether to invalidate the dirty buffers or not. For
> example, TryInvalidateBuffer(Buffer bufnum, bool force), if the force
> is set to FALSE, then ignore invalidating dirty buffers. Otherwise,
> flush the dirty buffer and try to invalidate.
>
> Second, In TryInvalidateBuffer(), it first checks if the reference
> count is greater than zero and then checks for dirty buffers. Will
> there be a scenario where the buffer is dirty and its reference count
> is zero? Can you please provide more information on this or adjust the
> code accordingly.
>
> > +/*
> > +Try Invalidating a buffer using bufnum.
> > +If the buffer is invalid, the function returns false.
> > +The function checks for dirty buffer and flushes the dirty buffer befo=
re invalidating.
> > +If the buffer is still dirty it returns false.
> > +*/
> > +bool
>
> The star(*) and space are missing here. Please refer to the style of
> function comments and change accordingly.
>
> Thanks & Regards,
> Nitin Jadhav
>
> On Fri, Jun 30, 2023 at 4:17=E2=80=AFPM Palak Chaturvedi
> <chaturvedipalak1911@gmail.com> wrote:
> >
> > I hope this email finds you well. I am excited to share that I have
> > extended the functionality of the `pg_buffercache` extension by
> > implementing buffer invalidation capability, as requested by some
> > PostgreSQL contributors for improved testing scenarios.
> >
> > This marks my first time submitting a patch to pgsql-hackers, and I am
> > eager to receive your expert feedback on the changes made. Your
> > insights are invaluable, and any review or comments you provide will
> > be greatly appreciated.
> >
> > The primary objective of this enhancement is to enable explicit buffer
> > invalidation within the `pg_buffercache` extension. By doing so, we
> > can simulate scenarios where buffers are invalidated and observe the
> > resulting behavior in PostgreSQL.
> >
> > As part of this patch, a new function or mechanism has been introduced
> > to facilitate buffer invalidation. I would like to hear your thoughts
> > on whether this approach provides a good user interface for this
> > functionality. Additionally, I seek your evaluation of the buffer
> > locking protocol employed in the extension to ensure its correctness
> > and efficiency.
> >
> > Please note that I plan to add comprehensive documentation once the
> > details of this enhancement are agreed upon. This documentation will
> > serve as a valuable resource for users and contributors alike. I
> > believe that your expertise will help uncover any potential issues and
> > opportunities for further improvement.
> >
> > I have attached the patch file to this email for your convenience.
> > Your valuable time and consideration in reviewing this extension are
> > sincerely appreciated.
> >
> > Thank you for your continued support and guidance. I am looking
> > forward to your feedback and collaboration in enhancing the PostgreSQL
> > ecosystem.
> >
> > The working of the extension:
> >
> > 1. Creating the extension pg_buffercache and then call select query on
> > a table and note the buffer to be cleared.
> > pgbench=3D# create extension pg_buffercache;
> > CREATE EXTENSION
> > pgbench=3D# select count(*) from pgbench_accounts;
> >  count
> > --------
> >  100000
> > (1 row)
> >
> > pgbench=3D# SELECT *
> > FROM pg_buffercache
> > WHERE relfilenode =3D pg_relation_filenode('pgbench_accounts'::regclass=
);
> >  bufferid | relfilenode | reltablespace | reldatabase | relforknumber
> > | relblocknumber | isdirty | usagecount | pinning_backends
> > ----------+-------------+---------------+-------------+---------------+=
----------------+---------+------------+------------------
> >       233 |       16397 |          1663 |       16384 |             0
> > |              0 | f       |          1 |                0
> >       234 |       16397 |          1663 |       16384 |             0
> > |              1 | f       |          1 |                0
> >       235 |       16397 |          1663 |       16384 |             0
> > |              2 | f       |          1 |                0
> >       236 |       16397 |          1663 |       16384 |             0
> > |              3 | f       |          1 |                0
> >       237 |       16397 |          1663 |       16384 |             0
> > |              4 | f       |          1 |                0
> >
> >
> > 2. Clearing a single buffer by entering the bufferid.
> > pgbench=3D# SELECT count(*)
> > FROM pg_buffercache
> > WHERE relfilenode =3D pg_relation_filenode('pgbench_accounts'::regclass=
);
> >  count
> > -------
> >   1660
> > (1 row)
> >
> > pgbench=3D# select pg_buffercache_invalidate(233);
> >  pg_buffercache_invalidate
> > ---------------------------
> >  t
> > (1 row)
> >
> > pgbench=3D# SELECT count(*)
> > FROM pg_buffercache
> > WHERE relfilenode =3D pg_relation_filenode('pgbench_accounts'::regclass=
);
> >  count
> > -------
> >   1659
> > (1 row)
> >
> > 3. Clearing the entire buffer for a relation using the function.
> > pgbench=3D# SELECT count(*)
> > FROM pg_buffercache
> > WHERE relfilenode =3D pg_relation_filenode('pgbench_accounts'::regclass=
);
> >  count
> > -------
> >   1659
> > (1 row)
> >
> > pgbench=3D# select count(pg_buffercache_invalidate(bufferid)) from
> > pg_buffercache where relfilenode =3D
> > pg_relation_filenode('pgbench_accounts'::regclass);
> >  count
> > -------
> >   1659
> > (1 row)
> >
> > pgbench=3D# SELECT count(*)
> > FROM pg_buffercache
> > WHERE relfilenode =3D pg_relation_filenode('pgbench_accounts'::regclass=
);
> >  count
> > -------
> >      0
> > (1 row)
> >
> >
> > Best regards,
> > Palak