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 1txw6Q-00H9rh-Hk for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Mar 2025 22:53:35 +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 1txw6P-00FIKI-8p for pgsql-hackers@arkaria.postgresql.org; Thu, 27 Mar 2025 22:53:33 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1txw6O-00FIKA-Op for pgsql-hackers@lists.postgresql.org; Thu, 27 Mar 2025 22:53:32 +0000 Received: from mail.postgrespro.ru ([93.174.132.70]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1txw6M-001aqb-1H for pgsql-hackers@lists.postgresql.org; Thu, 27 Mar 2025 22:53:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1743116009; bh=FDyI04HGteMOwl6pqB35xRiZc5/cCKc+f/Fd72sA1ts=; h=Date:From:To:Cc:Subject:In-Reply-To:References:Message-ID:From; b=Q82IJsdeL7FNgbIxWuEr1YXRA+88FlFUp7ejnXY2ZJvQzO1KO/RWvuvyv941UaBO/ aNblBL+WDOSGO8CLFVhtMwrr7V2JNKS9rMzUj2le5BrLnSBappT0Spg9Tkj7vhhVXu fxLcdL7NQxWa0nd73YNSb3PeRm/uQYNBNc50dvVmLx96d1Yfu+YXf10WwXvIZ/vUky PpwjrdGcDJ1okBnGNwKSQsyt98+O1LFjdZl33clMIgwS+xcERBHR0fMRA+7yw4raWR F3ZGQB0bSN+cxSpBRkvWK0zStDn3GGlp6TfzzYrNJvF4HEHHQqSWM0C+Hc+ctRTNQv BJhBUJJWnpMDg== Received: from mail.postgrespro.ru (webmail-master-mstn.l.postgrespro.ru [192.168.2.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: a.imamov@postgrespro.ru) by mail.postgrespro.ru (Postfix/587) with ESMTPSA id 3BEB16046E; Fri, 28 Mar 2025 01:53:29 +0300 (MSK) MIME-Version: 1.0 Date: Fri, 28 Mar 2025 01:53:29 +0300 From: Aidar Imamov To: Nazir Bilal Yavuz Cc: Joseph Koshakow , Andres Freund , PostgreSQL Hackers Subject: Re: Add pg_buffercache_evict_all() and pg_buffercache_mark_dirty[_all]() functions In-Reply-To: References: <568288111d505a81ebb2a89cea9eacb2@postgrespro.ru> Message-ID: X-Sender: a.imamov@postgrespro.ru Organization: PostgresPro Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-KSMG-AntiPhishing: NotDetected X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 2.1.0.7854, bases: 2025/03/27 16:40:00 #27840400 X-KSMG-AntiVirus-Status: NotDetected, skipped X-KSMG-LinksScanning: not scanned, disabled by settings X-KSMG-Message-Action: skipped X-KSMG-Rule-ID: 1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi! I've been looking at the patches v3 and there are a few things I want to talk about. EvictUnpinnedBuffer(): I think we should change the paragraph with "flushed" of the comment to something more like this: "If the buffer was dirty at the time of the call it will be flushed by calling FlushBuffer() and if 'flushed' is not NULL '*flushed' will be set to true." I also think it'd be a good idea to add null-checks for "flushed" before dereferencing it: > *flushed = false; > *flushed = true; If the (!buf_state) clause is entered then we assume that the header is not locked. Maybe edit the comment: "Lock the header if it is not already locked." -> "Lock the header"? > if (!buf_state) > { > /* Make sure we can pin the buffer. */ > ResourceOwnerEnlarge(CurrentResourceOwner); > ReservePrivateRefCountEntry(); > > /* Lock the header if it is not already locked. */ > buf_state = LockBufHdr(desc); > } EvictUnpinnedBuffersFromSharedRelation(): Maybe it will be more accurate to name the function as EvictRelUnpinnedBuffers()? I think the comment will seem more correct in the following manner: "Try to evict all the shared buffers containing provided relation's pages. This function is intended for testing/development use only! Before calling this function, it is important to acquire AccessExclusiveLock on the specified relation to avoid replacing the current block of this relation with another one during execution. If not null, buffers_evicted and buffers_flushed are set to the total number of buffers evicted and flushed respectively." I also think it'd be a good idea to add null-checks for "buffers_evicted" and "buffers_flushed" before dereferencing them: > *buffers_evicted = *buffers_flushed = 0; I think we don't need to check this clause again if AccessExclusiveLock was acquired before function call. Don't we? > if (BufTagMatchesRelFileLocator(&bufHdr->tag, &rel->rd_locator)) > { > if (EvictUnpinnedBuffer(buf, buf_state, &flushed)) > (*buffers_evicted)++; > if (flushed) > (*buffers_flushed)++; > } MarkUnpinnedBufferDirty(): I think the comment will seem more correct in the following manner: "Try to mark provided shared buffer as dirty. This function is intended for testing/development use only! Same as EvictUnpinnedBuffer() but with MarkBufferDirty() call inside. Returns true if the buffer was already dirty or it has successfully been marked as dirty." And also I think the function should return true at the case when the buffer was already dirty. What do you think? pg_buffercache_evict_relation(): "pg_buffercache_evict_relation function is intended to" - 'be' is missed here. pg_buffercache_mark_dirty(): Maybe edit the comment to: "Try to mark a shared buffer as dirty."? Maybe edit the elog text to: "bad shared buffer ID" - just to clarify the case when provided buffer number is negative (local buffer number). pg_buffercache_mark_dirty_all(): Maybe also edit the comment to: "Try to mark all the shared buffers as dirty."? bufmgr.h: I think it might be a good idea to follow the Postgres formatting style and move the function's arguments to the next line if they exceed 80 characters. regards, Aidar Imamov