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 1pb4hm-0001s4-Fa for pgsql-hackers@arkaria.postgresql.org; Sat, 11 Mar 2023 19:16:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pb4hl-0002CG-2M for pgsql-hackers@arkaria.postgresql.org; Sat, 11 Mar 2023 19:16:33 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pb4hk-0002C2-Lx for pgsql-hackers@lists.postgresql.org; Sat, 11 Mar 2023 19:16:32 +0000 Received: from mail-il1-x136.google.com ([2607:f8b0:4864:20::136]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pb4ha-0008Mh-Bm for pgsql-hackers@postgresql.org; Sat, 11 Mar 2023 19:16:31 +0000 Received: by mail-il1-x136.google.com with SMTP id b12so4905588ilf.9 for ; Sat, 11 Mar 2023 11:16:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20210112.gappssmtp.com; s=20210112; t=1678562181; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=TPD5Tt8tdr7rPNGoPsmRyAJHOzJIMfswM4f+XnMkFco=; b=qE/WDFH7iHXm+e7yXVhLPG75dME2i3dP3VNrZNdG1D/kQ5N/aLjswaHI1aBEoj0raY 9bjevEUON29+MCedWfalBRDXlPAu1TR0YBNct52kf1bYfBRiAw2jhDnN1fc4Jyec68Ks iPgFlUziautgyJi8j9Y0HVnQmsnNRqXsk9BMcPSe/lAEN7y7pWgiXpBy6Q4a7LwXF7pZ gJote/EhBxV/PlOblL/gs1KEKORcnnef6DN+EGJufk91JocFK+3F98/Bm5PfTxLzMuvR bdyqYMt5pVjhw2TVzn38v9DqbB1pdVsFO3hCppBT3MQT8NZpGgIxB2+FrNvcpwYSavBh vQxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678562181; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=TPD5Tt8tdr7rPNGoPsmRyAJHOzJIMfswM4f+XnMkFco=; b=uC/0gbQUnmbZ+D3EoOR/BjMgEJY4ZhYuuSfiUmU+9xIEddBdNk0E+R3q5oswo04FQl 25bswyVoYMWRcuSONKSKb+lzUifOSyFT/7IhuJW8ekzgoje1xwzH2leu83o7NElMK34y LALNQ1IMxpFlfTIbG9yyxfer7z7iY24IPPORXdAbE1voW6i94JgYEVgMk1wsdWMXvOOn RYP5wub3boDrQ8ItW+qeVvZPIHy1EW4uFdIZwYo30YY94H/OE5v92ep4MyS1HVrYKkjz Y/wddadW/6MBy1FEygemRL6hXuRJzqvTPyWTK2JN9QhnUrra6THL1/vRdHSBfLQOe+aA rt+g== X-Gm-Message-State: AO0yUKVhLlfii0dQJDDtKvb6wR4mW935APR5BeBGR3Wmhx51Ya2OQp8j nN0e7bLFvF/OA1ilFm4iuiPjjw== X-Google-Smtp-Source: AK7set/DPMfjvQPyPD8g4IFnlti5/3C2rHFAc+AsWp39l1t/avDCQifF6B1UIjbpzl7Ug7EjbwJsiQ== X-Received: by 2002:a05:6e02:144f:b0:316:e3a0:723f with SMTP id p15-20020a056e02144f00b00316e3a0723fmr8458905ilo.17.1678562181479; Sat, 11 Mar 2023 11:16:21 -0800 (PST) Received: from pryzbyj.telsasoft (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id b16-20020a92dcd0000000b0031595ea003asm1020743ilr.85.2023.03.11.11.16.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 11 Mar 2023 11:16:20 -0800 (PST) Received: by pryzbyj.telsasoft (Postfix, from userid 1000) id 0EAA180621B; Sat, 11 Mar 2023 13:16:20 -0600 (CST) Date: Sat, 11 Mar 2023 13:16:19 -0600 From: Justin Pryzby To: Melanie Plageman Cc: Bharath Rupireddy , Andres Freund , Tom Lane , Peter Geoghegan , pgsql-hackers@postgresql.org, Robert Haas , David Rowley Subject: Re: Option to not use ringbuffer in VACUUM, using it in failsafe mode Message-ID: References: <20230111185854.5srlvequbxbg5p6c@awork3.anarazel.de> <20230111191842.5ywh7twkis42kxad@awork3.anarazel.de> <669645.1673471914@sss.pgh.pa.us> <20230111213905.4ljixbm2oyqzvzzx@awork3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sat, Mar 11, 2023 at 09:55:33AM -0500, Melanie Plageman wrote: > Subject: [PATCH v3 2/3] use shared buffers when failsafe active > > + /* > + * Assume the caller who allocated the memory for the > + * BufferAccessStrategy object will free it. > + */ > + vacrel->bstrategy = NULL; This comment could use elaboration: ** VACUUM normally restricts itself to a small ring buffer; but in failsafe mode, in order to process tables as quickly as possible, allow the leaving behind large number of dirty buffers. > Subject: [PATCH v3 3/3] add vacuum option to specify ring_size and guc > #define INT_ACCESS_ONCE(var) ((int)(*((volatile int *)&(var)))) > +#define bufsize_limit_to_nbuffers(bufsize) (bufsize * 1024 / BLCKSZ) Macros are normally be capitalized It's a good idea to write "(bufsize)", in case someone passes "a+b". > @@ -586,6 +587,45 @@ GetAccessStrategy(BufferAccessStrategyType btype) > +BufferAccessStrategy > +GetAccessStrategyWithSize(BufferAccessStrategyType btype, int ring_size) Maybe it would make sense for GetAccessStrategy() to call GetAccessStrategyWithSize(). Or maybe not. > + {"vacuum_buffer_usage_limit", PGC_USERSET, RESOURCES_MEM, > + gettext_noop("Sets the buffer pool size for operations employing a buffer access strategy."), The description should mention vacuum, if that's the scope of the GUC's behavior. > +#vacuum_buffer_usage_limit = -1 # size of vacuum buffer access strategy ring. > + # -1 to use default, > + # 0 to disable vacuum buffer access strategy and use shared buffers > + # > 0 to specify size If I'm not wrong, there's still no documentation about "ring buffers" or postgres' "strategy". Which seems important to do for this patch, along with other documentation. This patch should add support in vacuumdb.c. And maybe a comment about adding support there, since it's annoying when it the release notes one year say "support VACUUM (FOO)" and then one year later say "support vacuumdb --foo". -- Justin