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 1pKpBc-0005QR-Lo for pgsql-admin@arkaria.postgresql.org; Wed, 25 Jan 2023 23:28:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pKpBb-0003ZZ-J2 for pgsql-admin@arkaria.postgresql.org; Wed, 25 Jan 2023 23:28:11 +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 1pKpBa-0003YY-JG for pgsql-admin@lists.postgresql.org; Wed, 25 Jan 2023 23:28:11 +0000 Received: from resqmta-c1p-023832.sys.comcast.net ([2001:558:fd00:56::9]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pKpBW-0007FR-QW for pgsql-admin@lists.postgresql.org; Wed, 25 Jan 2023 23:28:08 +0000 Received: from resomta-c1p-022592.sys.comcast.net ([96.102.18.237]) by resqmta-c1p-023832.sys.comcast.net with ESMTP id Kp50p7EpSxq24KpBTpIuDK; Wed, 25 Jan 2023 23:28:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1674689283; bh=zxC5qmfIeeBzyvtigYIaNuYFF2HXfMYTKkyTF5r2fqI=; h=Received:Received:Received:From:To:Subject:Date:Message-ID: MIME-Version:Content-Type:Xfinity-Spam-Result; b=Cop0PQ/dyMbJBO5VJZAo05I3DMNYOjKifYVXi5YHjgxz+sIeSyYVsTUSugB2tq6xj odNPhWUBppDZJF+Qab36TlcnpXbJvQKGTGqjgpHRiA0QscYJyOKdqjfGa3bsWxbGgZ D7DV9L0WuTSrH1jn1Xjz7JpcWCNPCdPY+THDVGNx0GjxTQuHR9PyXBjIfJUpYGiK21 1bg7IG2/kKZBxAKmwru0efrZAxBHMKT6CJb2t6l7wpMz+qEXEw7stggiwFQQMZhh0s qwkZ4RbUjMub77BXu233ffDHGbmJX2c6ulMBZOtW0JcNLLjh8kGc/VJsfiSW+z7smn tDdXPxcU5t63Q== Received: from R9N0YC2TC3.localdomain ([IPv6:2601:249:8780:7950:fd85:63d2:464f:61ea]) by resomta-c1p-022592.sys.comcast.net with ESMTPA id KpBRpt7KwikxiKpBSpCDmd; Wed, 25 Jan 2023 23:28:03 +0000 X-Xfinity-VMeta: sc=0.00;st=legit Received: by R9N0YC2TC3.localdomain (Postfix, from userid 503) id 0555B119B99C; Wed, 25 Jan 2023 17:28:01 -0600 (CST) From: Jerry Sievers To: Tom Lane Cc: pgsql-admin@lists.postgresql.org Subject: Re: Does raising maintenance_work_mem get seen by an already running aucovac? References: <2845694.1674682563@sss.pgh.pa.us> Date: Wed, 25 Jan 2023 17:28:00 -0600 In-Reply-To: <2845694.1674682563@sss.pgh.pa.us> (Tom Lane's message of "Wed, 25 Jan 2023 16:36:03 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.1 (darwin) MIME-Version: 1.0 Content-Type: text/plain List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Tom Lane writes: > Jerry Sievers writes: > >> There's a long running anti-wrap autovac that we'd rather let finish but >> on the server instance, I found maintenance_work_mem rather low and thus >> raised it in postgresql.comf, reloaded and confirmed that my interactive >> session saw the change. > >> Can a running autovac make use of this or should I either wait it out or >> cancel and let it restart when ready? > > Looks like an autovac worker will notice postgresql.conf changes once > per table: > > /* > * Perform operations on collected tables. > */ > foreach(cell, table_oids) > { > ... > > /* > * Check for config changes before processing each collected table. > */ > if (ConfigReloadPending) > ProcessConfigFile(PGC_SIGHUP); > > If it is stuck on a particularly enormous table, you might be best off > to kill it, but otherwise I'd let it go. > > regards, tom lane Thanks Tom! That's the situation, the >1TB table is just chugging along. So, a live individual vacuum of a particulart table will not start using more mwm but later tasks will. In fact, the existing setting which I believed too small probably does exceed the 1G limit of some kind that's explained in the docs and ps shows that process having about 1G of memory allocated, so perhaps the frobbling wasn't too useful a fix. Ack'd I'll keep an eye on things.