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 1nKpjb-000310-Vu for pgsql-hackers@arkaria.postgresql.org; Thu, 17 Feb 2022 22:58:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nKpjZ-00029J-RS for pgsql-hackers@arkaria.postgresql.org; Thu, 17 Feb 2022 22:58: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 1nKpjZ-00029A-IB for pgsql-hackers@lists.postgresql.org; Thu, 17 Feb 2022 22:58:45 +0000 Received: from mail-pj1-x102a.google.com ([2607:f8b0:4864:20::102a]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nKpjW-0007qs-Oh for pgsql-hackers@postgresql.org; Thu, 17 Feb 2022 22:58:45 +0000 Received: by mail-pj1-x102a.google.com with SMTP id v13-20020a17090ac90d00b001b87bc106bdso10710644pjt.4 for ; Thu, 17 Feb 2022 14:58:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=jLLeqBD+pxqw0KS3kGgqZsGWcRi0pKcj6uKhcR5TF/Y=; b=PFYJmUR/BAKl/jaWIwoP1AGzYMI7mO2Wq8NC2zSrvfM7pE1MS7E5hMx3h0o3V0SxuD vaW/AXl11cAEE+DxO6xTnhyYvzq2DrFaTMmXsZmrgILGvv1o87qvT+ODRNE0cNfLymWH D6i8taam0xtnqUVZmrpfRr6fhfdJvppQ9WVpkmNYBxnU2O6IvlqnF+pjoTRfL4AcG30n mBvAaORy1ovRJe82HnlmZMNy/evjVeFlqAiXw21hL0xIUeclg5OvOXUTo+uZTeEp27xf M0pGp8Nfv6CQH381JI+9zGmKyVXpD7X5zHsy893n/7+QCOOOwdw3+uBJQBcJxr/Otcwl yFsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=jLLeqBD+pxqw0KS3kGgqZsGWcRi0pKcj6uKhcR5TF/Y=; b=R9a0Riup2geabFIZ1BtKmU4K0hj0U1kbHI1Hq4qdKXfljRX/gPW7veZPf4715Mjq7A uqrGPBRl0kx/y5kLcTcTnHxmFZ6McXz576DsJYVJAznI4zILDOzhPRK+/Q/R0Di+PqCm 2L0Xg/1rplVG+f1LvlajijpBOuULRHPUTuA/qfJp5i1hsAPMuiYuBn3if+VdGyrdvrUc A0tC97CdvuNSNsLfdSPOAmmkcBmyHPQ+auoypqi61+xGP0twBxwLQ6jjYHYQXgQKarsW i3IuH/rsiiHJAFs+Kq7BGMZNK4WrzMlHl5SVy3Kq9rKfMCPeVB6COrPhPZiCmCjspvra /q2A== X-Gm-Message-State: AOAM530GQjiEbPuC19TIl8SyRbXHgY2TYVYXlD3IhlIAvs6M6e6ZR5Kn y8Nnvzz08E6qg0pV6ss5DZU= X-Google-Smtp-Source: ABdhPJyMQkTXvJgAe6RNzzPpIYAojY6nlUuga+oV/NCJVTnYGtVgttBf9VmkgszFqiyL9H3uqZstGA== X-Received: by 2002:a17:902:c9c3:b0:14f:e0b:2abe with SMTP id q3-20020a170902c9c300b0014f0e0b2abemr4800471pld.114.1645138720418; Thu, 17 Feb 2022 14:58:40 -0800 (PST) Received: from nathanxps13 ([50.54.155.70]) by smtp.gmail.com with ESMTPSA id g5sm608566pfv.22.2022.02.17.14.58.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Feb 2022 14:58:39 -0800 (PST) Date: Thu, 17 Feb 2022 14:58:38 -0800 From: Nathan Bossart To: Andres Freund Cc: "Bossart, Nathan" , Bharath Rupireddy , Maxim Orlov , Amul Sul , Bruce Momjian , Robert Haas , "pgsql-hackers@postgresql.org" Subject: Re: O(n) tasks cause lengthy startups and checkpoints Message-ID: <20220217225838.GA3292179@nathanxps13> References: <83A7426F-A7B6-4A10-A8F0-179AE30B871D@amazon.com> <20220211180249.GA1886051@nathanxps13> <20220217005057.GA3201038@nathanxps13> <20220217015052.2y3wxibeommk37ey@alap3.anarazel.de> <20220217041404.GA3243546@nathanxps13> <20220217065938.x2esfdppzypegn5j@alap3.anarazel.de> <20220217182337.GA3247866@nathanxps13> <20220217192709.eyf2cnymhxqsals7@alap3.anarazel.de> <20220217210022.GA3248793@nathanxps13> <20220217222829.lndzwq72fh4v34c2@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220217222829.lndzwq72fh4v34c2@alap3.anarazel.de> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Feb 17, 2022 at 02:28:29PM -0800, Andres Freund wrote: > As far as I understand, the primary concern are logical decoding serialized > snapshots, because a lot of them can accumulate if there e.g. is an old unused > / far behind slot. It should be easy to reduce the number of those snapshots > by e.g. eliding some redundant ones. Perhaps we could also make backends in > logical decoding occasionally do a bit of cleanup themselves. > > I've not seen reports of the number of mapping files to be an real issue? I routinely see all four of these tasks impacting customers, but I'd say the most common one is the temporary file cleanup. Besides eliminating some redundant files and having backends perform some cleanup, what do you think about skipping the logical decoding cleanup during end-of-recovery/shutdown checkpoints? This was something that Bharath brought up a while back [0]. As I noted in that thread, startup and shutdown could still take a while if checkpoints are regularly delayed due to logical decoding cleanup, but that might still help avoid a bit of downtime. > The improvements around deleting temporary files and serialized snapshots > afaict don't require a dedicated process - they're only relevant during > startup. We could use the approach of renaming the directory out of the way as > done in this patchset but perform the cleanup in the startup process after > we're up. Perhaps this is a good place to start. As I mentioned above, IME the temporary file cleanup is the most common problem, so I think even getting that one fixed would be a huge improvement. [0] https://postgr.es/m/CALj2ACXkkSL8EBpR7m%3DMt%3DyRGBhevcCs3x4fsp3Bc-D13yyHOg%40mail.gmail.com -- Nathan Bossart Amazon Web Services: https://aws.amazon.com