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 1pAeZT-0007uU-Mz for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Dec 2022 22:06: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 1pAeYT-0000P2-Du for pgsql-hackers@arkaria.postgresql.org; Wed, 28 Dec 2022 22:05: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 1pAeYT-0000Oi-4i for pgsql-hackers@lists.postgresql.org; Wed, 28 Dec 2022 22:05:45 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pAeYR-0003La-3y for pgsql-hackers@lists.postgresql.org; Wed, 28 Dec 2022 22:05:44 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 2BSM5dHw424446; Wed, 28 Dec 2022 17:05:39 -0500 From: Tom Lane To: Nathan Bossart cc: Peter Geoghegan , postgresql@taljaren.se, pgsql-hackers@lists.postgresql.org, Michael Paquier Subject: Re: BUG #17717: Regression in vacuumdb (15 is slower than 10/11 and possible memory issue) In-reply-to: <20221228212150.GA4009813@nathanxps13> References: <17717-6c50eb1c7d23a886@postgresql.org> <3439037.1671130590@sss.pgh.pa.us> <3544447.1671141436@sss.pgh.pa.us> <3672943.1671202149@sss.pgh.pa.us> <407579.1672258403@sss.pgh.pa.us> <20221228212150.GA4009813@nathanxps13> Comments: In-reply-to Nathan Bossart message dated "Wed, 28 Dec 2022 13:21:50 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <424444.1672265139.1@sss.pgh.pa.us> Date: Wed, 28 Dec 2022 17:05:39 -0500 Message-ID: <424445.1672265139@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Nathan Bossart writes: > On Wed, Dec 28, 2022 at 03:13:23PM -0500, Tom Lane wrote: >> + executeCommand(conn, "VACUUM (ONLY_DATABASE_STATS);", echo); > When I looked at this, I thought it would be better to send the command > through the parallel slot machinery so that failures would use the same > code path as the rest of the VACUUM commands. However, you also need to > adjust ParallelSlotsWaitCompletion() to mark the slots as idle so that the > slot array can be reused after it is called. Hm. I was just copying the way commands are issued further up in the same function. But I think you're right: once we've done ParallelSlotsAdoptConn(sa, conn); it's probably not entirely kosher to use the conn directly. regards, tom lane