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 1pOpeZ-0000qk-J4 for pgsql-hackers@arkaria.postgresql.org; Mon, 06 Feb 2023 00:46:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pOpeY-0006yx-Ct for pgsql-hackers@arkaria.postgresql.org; Mon, 06 Feb 2023 00:46:38 +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 1pOpeY-0006yo-3Z for pgsql-hackers@lists.postgresql.org; Mon, 06 Feb 2023 00:46:38 +0000 Received: from mail-pj1-x1036.google.com ([2607:f8b0:4864:20::1036]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pOpeV-0001bz-NB for pgsql-hackers@lists.postgresql.org; Mon, 06 Feb 2023 00:46:37 +0000 Received: by mail-pj1-x1036.google.com with SMTP id v6-20020a17090ad58600b00229eec90a7fso12271563pju.0 for ; Sun, 05 Feb 2023 16:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; 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=dFj1evusstdO1vZaDXd1uPLAaQFEuvJcUFQcom/D0HM=; b=aF41RM1/PHYbiU7ZagMZmYudyRDiaqVX1EedhNvEb8IXpxqTjN6WqUkveMPVY6gQ1u D7YPp9Smn2sz3MTNKm/rdh8si1aVIgOUz19SEMVJZWJuL9x6q35BcVBsOV8jB0v78+We PhXBNz1DWXjcImA7hci2Tnwqc61mnNZneMDcGPT909mssfmeah5G9SzuG0M0cGUNVT0m tqjPwjxPUAnG38UxWh1C8aHG6JIhkBUCvZYoQCKvgFBrC6ji4C05o8iT06aVdiJy2nQL kK6Fc05S9GX4ZM+iAelBvRyIiaa7/3YyXUjTfn4gVxyalw6yOO3C8DEy6hbaDJ4R7IXG LRhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=dFj1evusstdO1vZaDXd1uPLAaQFEuvJcUFQcom/D0HM=; b=dGKRaIn3tDLHkeheWGtYhU8t3P1YcdxNGbKDuRGuUELdZD4G65PeAPUKGkCU8URUZg T6NQxc1AMqcLYENEzBJbj0uBBkIVObW71NWLTjzvn4EMkISokY6xpMSM+k0Cbo0cp8C6 BdcoBgS1kp9gqNysl5J1FhtSUrx7ZCOqWPZ7Xx4BE38YNSGw4/eUmET3hShw/8tmWF3B iz9dn5yWi6K0UNkY8w4B6Bt2Tdp3YcKe6gY1V5iKGL3W0F7tcwLUhAk57RMQeuAJXyd3 KJmKr4xqCsBeQnxj8HcoTeMht/Av3sZp+okn68rYJfSc5p5qh9MV9aWjG0nksD3NEw2C b7Tg== X-Gm-Message-State: AO0yUKXAB1kgovQ+gHVd0kVQB0vsFD+HDGM2fQJkKHhrD6ltlNrP43vk LG7IfC4AdhNW2ZF2ITb7RKQ= X-Google-Smtp-Source: AK7set+EqmYY7LGUTR4BDGwjnnaIUU3UthgaAm8Zo/jwkAxDsP/2E8MfWzSyA+HhvSeVsXqaFTTRLQ== X-Received: by 2002:a17:902:d1d1:b0:199:4ea:866e with SMTP id g17-20020a170902d1d100b0019904ea866emr3234586plb.40.1675644394068; Sun, 05 Feb 2023 16:46:34 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id jc10-20020a17090325ca00b00199190b00efsm502418plb.97.2023.02.05.16.46.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Feb 2023 16:46:33 -0800 (PST) Date: Sun, 5 Feb 2023 16:46:31 -0800 From: Nathan Bossart To: Andres Freund Cc: Michael Paquier , Tom Lane , Thomas Munro , Fujii Masao , Postgres hackers Subject: Re: Weird failure with latches in curculio on v15 Message-ID: <20230206004631.GA277434@nathanxps13> References: <20230201175806.GA3199959@nathanxps13> <20230201223555.GA3721373@nathanxps13> <20230204113029.xlcqrbxhp6lerrnc@alap3.anarazel.de> <20230204180354.GA258107@nathanxps13> <20230205221938.GA274245@nathanxps13> <20230205230157.45kl5gqryupzdoyb@alap3.anarazel.de> <20230205235747.GA275913@nathanxps13> <20230206000750.ohqjmbfo3trtwvhc@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230206000750.ohqjmbfo3trtwvhc@alap3.anarazel.de> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sun, Feb 05, 2023 at 04:07:50PM -0800, Andres Freund wrote: > On 2023-02-05 15:57:47 -0800, Nathan Bossart wrote: >> I agree that the shell overhead isn't the main performance issue, >> but it's unclear to me how much of this should be baked into >> PostgreSQL. > > I don't know fully either. But just reimplementing all of it in > different modules doesn't seem like a sane approach either. A lot of it > is policy that we need to solve once, centrally. > >> I mean, we could introduce a GUC that tells us how far ahead to >> restore and have a background worker (or multiple background workers) >> asynchronously pull files into a staging directory via the callbacks. >> Is that the sort of scope you are envisioning? > > Closer, at least. Got it. I suspect we'll want to do something similar for archive modules eventually, too. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com