Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qH1Xv-0002AI-9I for pgsql-hackers@arkaria.postgresql.org; Wed, 05 Jul 2023 12:23:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1qH1Xt-0000kp-RB for pgsql-hackers@arkaria.postgresql.org; Wed, 05 Jul 2023 12:23:45 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qH1Xt-0000kg-GW for pgsql-hackers@lists.postgresql.org; Wed, 05 Jul 2023 12:23:45 +0000 Received: from mail-lf1-x136.google.com ([2a00:1450:4864:20::136]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1qH1Xq-002LOK-UO for pgsql-hackers@postgresql.org; Wed, 05 Jul 2023 12:23:44 +0000 Received: by mail-lf1-x136.google.com with SMTP id 2adb3069b0e04-4fba1288bbdso8897745e87.1 for ; Wed, 05 Jul 2023 05:23:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1688559821; x=1691151821; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Ihx7smcO4kwa0o3kCq7KPO78OUcNe3Tzd8wKJnBphv8=; b=MZxeZ1qfKuVLt5vl1eQ+Q4mvNAcVub9Krqe16q+LspPR134bmKl61RMlveq6DHf79Z VTKvJijTwQ80gcdm7MRdDQvnl6ENbuyir42mSKfkLKFdBnmJD4oD/VEEg2tghAEHHL0r eplgGZaG0rdN0V5zE1FKYdvlzDTcop1obPafP3RxzYSZYDcZcHif+jOY99Mxj+TCD4bk /d8xrKBfGQTgJGo05fffrnkncHqG3mi9sBlhLK0JAP7GQ/1bPSdwnYCYHGoWR11Fqxqp g4pcTEdKrRagmQaECsdEhMuNFGGu8q3etCn+L8PyOpu6VFY72fOSO09nXYoQ2cv5PRYp eIaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688559821; x=1691151821; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Ihx7smcO4kwa0o3kCq7KPO78OUcNe3Tzd8wKJnBphv8=; b=FILUtpW+DaNeVIQOm79nn5VXkAuwZD/y4OrSMoYU99E7hybWMi3czs3oKxnv23nzWJ SaFjwNYFcHrFfZVZb6esHG9ysaD2afva9g4U+SWJY4OUWOLaMLj9GkZLSzRFAxMkZuhM lNv8OKe9RNf0vS4QvvvTiuGM44MizWDMrHheVF++a0oMK0RPdQrNCO2n+xbG/yYcHoLD v2ha8fUxWRQdqvmlW3qkH2dmj3LI6B7ITDfXN6RwEQb9ZK5i97iS8/RPyVelQJ37KGdk PEbmAob8pWWbxHSTwLOIZLWxyxGhHQSfVl/eeK3BrKyPHbbrhKRwkgyTtPT2oq6Ai4Zk PO3Q== X-Gm-Message-State: ABy/qLY+RHWWNSHs/pACmCXNr8ZnzsUFbtrr2Bjx6Wps2nPOgHo5ENUG ME7nhKI9IRbk9K2CQaECBhjBFan8dspp/WbNIOw= X-Google-Smtp-Source: APBJJlFw8IBOQCO6PD/ku5bqN7Gh+TcD+TpCtDZDkpB0hTS+UAAtAoB41+y1FmzM4ptIrBB8GXAIZlnXFV48MKRRolI= X-Received: by 2002:a05:6512:3b0f:b0:4f9:6528:fb1e with SMTP id f15-20020a0565123b0f00b004f96528fb1emr16300911lfv.51.1688559820650; Wed, 05 Jul 2023 05:23:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nitin Jadhav Date: Wed, 5 Jul 2023 17:53:04 +0530 Message-ID: Subject: Re: Extension Enhancement: Buffer Invalidation in pg_buffercache To: Palak Chaturvedi Cc: pgsql-hackers@postgresql.org, thomas.munro@microsoft.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk +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 before= 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 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