Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rthAS-00GnII-Qx for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Apr 2024 05:03:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rthAR-000JGV-T2 for pgsql-hackers@arkaria.postgresql.org; Mon, 08 Apr 2024 05:03:39 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rthAR-000JFf-JT for pgsql-hackers@lists.postgresql.org; Mon, 08 Apr 2024 05:03:39 +0000 Received: from mail-lf1-x135.google.com ([2a00:1450:4864:20::135]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rthAP-001lYM-2h for pgsql-hackers@postgresql.org; Mon, 08 Apr 2024 05:03:38 +0000 Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-5171a529224so351611e87.0 for ; Sun, 07 Apr 2024 22:03:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712552615; x=1713157415; darn=postgresql.org; 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=dZkyVqBRMav2bmJbYe9DYC1DCJ3MucqaRM6ZqMwafVU=; b=Q45bbfm0QS/O8euzdOwewpnzUruH4XaSH+HG5CsY3SPt5dfqEUKTJ/jMWyP32o2zWP 7cOVMMRW53k5u9dquiR0cTzTWinIA9YUKjPKeoq/r4o8impFPa7Bnw25Z0RM/QSzy7h9 qoYl/krJara4cG2hWKUywzXz2INvCpzGVX4fiesNAVXeBrDY0wEQj3nEPZoa2KO+ha0E uiQFVMBqwfdHybq4zKbwskQZhEbXusyZhgbY5B3qh4NRhMpwlcnxQlDDh7E2gozT0IvK 4x7g5+sBMDL/BGlmik/vKSydEGrT3CX0J235O6z2Lo3MQGNg3BRuKb4jtjPNsMNlhBCj W71Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712552615; x=1713157415; 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=dZkyVqBRMav2bmJbYe9DYC1DCJ3MucqaRM6ZqMwafVU=; b=D2n1HJRtzKAWasut8dS0sCr7rVE5q4dmbvqAxIXTQHiNvhqpUX8XpnC/WhDb8xgF9C zpwhkckJtbgL81iejZ0R0rO2VWmPFG5cu6G9dXCfD64AfFAzqbqRGd06eRquOM83i6ME h/SrEosiDTBNi+2m+aFxdreBWem28ZhsgB2h6yc1woa2Fm0tatUpFZYEkLMXpMcn6md7 E4+OxOpcWFhTT6liLQPfKF/k+p1nd4fK1w39BIj3MeswqCRbuycy7JFIZE9FnWM5JROW I7Q9/op7fSzL1Tyr/Xvpx6AFhevH7OCAgEhfK20Shs4hasF7PQjkH/mKWS71eKqB5rPQ 0chA== X-Forwarded-Encrypted: i=1; AJvYcCVMv3GMAruqGRAwSrVwDuNAI0WUwzEDT4pQApHSKdJxeJEdASLaop9rUsJC8cYrwhIo0vZxanNLuUN+PXXGYGW5fSQesgc1VOvZa6q1 X-Gm-Message-State: AOJu0YwQ4vwlI8TVc9ISqW9uf+T3rZ65OtShYctc6ou+sQGcTlxCfM8q RU11y0aA1tV7xDVMIS1/83CdJV0E0qZlGzKNobSdv6C/T+9SEBWxajUG0+BXAtGQy8wPc/qVbPt IZpwjnPXRN1nCo3fCgLDnS6Hd4NITJCmqgAQ= X-Google-Smtp-Source: AGHT+IHbyFe4T2aR+OLzs8PeN+Rj8Hn7c65TX7W7YjgECsGscy1TSIRKNUJgfM/3LZG/lLyFhSA6CmmE/rwV3N9LKD4= X-Received: by 2002:ac2:4842:0:b0:516:9ec1:b197 with SMTP id 2-20020ac24842000000b005169ec1b197mr4908347lfy.36.1712552615189; Sun, 07 Apr 2024 22:03:35 -0700 (PDT) MIME-Version: 1.0 References: <8b8c709a-c7cc-4965-8296-64f549c27501@abcsql.com> <3510716d-d3f3-40c8-9f7f-d644171acfb6@gmail.com> In-Reply-To: From: Thomas Munro Date: Mon, 8 Apr 2024 17:02:58 +1200 Message-ID: Subject: Re: Extension Enhancement: Buffer Invalidation in pg_buffercache To: Melanie Plageman Cc: Maxim Orlov , vignesh C , Palak Chaturvedi , Jim Nasby , pgsql-hackers@postgresql.org, Nitin Jadhav 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 On Mon, Apr 8, 2024 at 11:53=E2=80=AFAM Melanie Plageman wrote: > I've reviewed v6. I think you should mention in the docs that it only > works for shared buffers -- so specifically not buffers containing > blocks of temp tables. Thanks for looking! The whole pg_buffercache extension is for working with shared buffers only, as mentioned at the top. I have tried to improve that paragraph though, as it only mentioned examining them. > In the function pg_buffercache_invalidate(), why not use the > BufferIsValid() function? > > - if (buf < 1 || buf > NBuffers) > + if (!BufferIsValid(buf) || buf > NBuffers) It doesn't check the range (it has assertions, not errors). > I thought the below would be more clear for the comment above > InvalidateUnpinnedBuffer(). > > - * Returns true if the buffer was valid and it has now been made invalid= . > - * Returns false if the wasn't valid, or it couldn't be evicted due to a= pin, > - * or if the buffer becomes dirty again while we're trying to write it o= ut. > + * Returns true if the buffer was valid and has now been made invalid. R= eturns > + * false if it wasn't valid, if it couldn't be evicted due to a pin, or = if the > + * buffer becomes dirty again while we're trying to write it out. Fixed. > Some of that probably applies for the docs too (i.e. you have some > similar wording in the docs). There is actually one typo in your > version, so even if you don't adopt my suggestion, you should fix that > typo. Yeah, thanks, improved similarly there. > I didn't notice anything else out of place. I tried it and it worked > as expected. I'm excited to have this feature! Thanks! > I didn't read through this whole thread, but was there any talk of > adding other functions to let me invalidate a bunch of buffers at once > or even some options -- like invalidate every 3rd buffer or whatever? > (Not the concern of this patch, but just wondering because that would > be a useful future enhancement IMO). TBH I tried to resist people steering in that direction because you can also just define a SQL function to do that built on this, and if you had specialised functions they'd never be quite right. IMHO we succeeded in minimising the engineering and maximising flexibility, 'cause it's for hackers. Crude, but already able to express a wide range of stuff by punting the problem to SQL. Thanks to Palak for the patch. Pushed.