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 1pOnMQ-0002SQ-B6 for pgsql-hackers@arkaria.postgresql.org; Sun, 05 Feb 2023 22:19:46 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pOnMP-0006sN-7f for pgsql-hackers@arkaria.postgresql.org; Sun, 05 Feb 2023 22:19:45 +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 1pOnMO-0006q7-U1 for pgsql-hackers@lists.postgresql.org; Sun, 05 Feb 2023 22:19:44 +0000 Received: from mail-pl1-x633.google.com ([2607:f8b0:4864:20::633]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pOnMM-0006Rs-Gd for pgsql-hackers@lists.postgresql.org; Sun, 05 Feb 2023 22:19:43 +0000 Received: by mail-pl1-x633.google.com with SMTP id h15so2964512plk.12 for ; Sun, 05 Feb 2023 14:19:42 -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=xGP7h2hjDdSALPxA2+0vcncYx4N5LTHEo8nyFX+kAJ0=; b=P7EjA3ssjubpCz880qSz5ImOTkIi5alFgITe0NiVAKjPortQJEQEZlTOOxgKlzAlWR r4+tSfl5DyTHq6a4a+QKb/VLdKWQQCj1UXRHdmjccHzcLK1bkixXFDThzA5iij58HAR9 75DtMBGWY4tBAqywwQ3F3Bbef5c/+k2NR3G3uyqxYNJEtfAEyPPpYSgjgUEOpdFR3rKa 0t532tGweM5o/hdLdJEhavbrsvyQDk4liZzu3k4itpIiCM6Ry6C+HDc4t5YUGPKO0hjH KBeOKeBSW/0dxkPXXKcVFfbgLC9rMann4VZj7e5kZkzMJl5KeI6Ob7V3IWetejJoW0GM KumQ== 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=xGP7h2hjDdSALPxA2+0vcncYx4N5LTHEo8nyFX+kAJ0=; b=n48E6q5p+k0juHSgE183iMqKReCVPt3rFJBqkcUUbx5bXmvpmGQB/qZhFDdc9tdgV4 8h1IF8PIekFEqiJRA+EWoex6i6721hoJYy0GjYGz9WZjfGkN0tdlIN+30XHa+PgjpNZt 0R5seU6TkUWmGsGwexdwugDgO/3Zc0TgwHMGt6fSgZCUQ/atTpkbS7btGZKG70ICKGGJ Ep5KlxaUokDejlpA7R0spj1YJZxOb+5IrlkRXtxWYWkJzEIz7ERqMCrUPixDUO0stG3m tdopsPShky27Z5s7n6V6+Sl05gf0JjRzR4a4ycmxKsJ/muacnd7bFz7+4zpN6V9BosaS SAqg== X-Gm-Message-State: AO0yUKX6vPdbeFPWfymUz+zrNyWm2SO5owjOzdPftm3BkVAD5NbhDAlN mBDTfQh5+iew9fez07/YVek= X-Google-Smtp-Source: AK7set/D2nsuPXaG2X2m3qdzJxR79WlLbvV7G0pSh5N6NbRJq3Cnbk27fZLm+kqik38QKMJ/QbLa4g== X-Received: by 2002:a05:6a21:8695:b0:bf:6cd3:9546 with SMTP id ox21-20020a056a21869500b000bf6cd39546mr13171434pzb.30.1675635581052; Sun, 05 Feb 2023 14:19:41 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id d9-20020a63a709000000b004b1b9e23790sm4769432pgf.92.2023.02.05.14.19.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Feb 2023 14:19:40 -0800 (PST) Date: Sun, 5 Feb 2023 14:19:38 -0800 From: Nathan Bossart To: Michael Paquier Cc: Andres Freund , Tom Lane , Thomas Munro , Fujii Masao , Postgres hackers Subject: Re: Weird failure with latches in curculio on v15 Message-ID: <20230205221938.GA274245@nathanxps13> References: <20230201105514.rsjl4bnhb65giyvo@alap3.anarazel.de> <1369666.1675264346@sss.pgh.pa.us> <20230201165801.33ydbxvjdbomjqa7@alap3.anarazel.de> <20230201175806.GA3199959@nathanxps13> <20230201223555.GA3721373@nathanxps13> <20230204113029.xlcqrbxhp6lerrnc@alap3.anarazel.de> <20230204180354.GA258107@nathanxps13> 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 Sun, Feb 05, 2023 at 09:49:57AM +0900, Michael Paquier wrote: > - Should we include archive_cleanup_command into the recovery modules > at all? We've discussed offloading that from the checkpointer, and it > makes the failure handling trickier when it comes to unexpected GUC > configurations, for one. The same may actually apply to > restore_end_command. Though it is done in the startup process now, > there may be an argument to offload that somewhere else based on the > timing of the end-of-recovery checkpoint. My opinion on this stuff is > that only including restore_command in the modules would make most > users I know of happy enough as it removes the overhead of the command > invocation from the startup process, if able to replay things fast > enough so as the restore command is the bottleneck. > restore_end_command would be simple enough, but if there is a wish to > redesign the startup process to offload it somewhere else, then the > recovery module makes backward-compatibility concerns harder to think > about in the long-term. I agree. I think we ought to first focus on getting the recovery modules interface and restore_command functionality in place before we take on more difficult things like archive_cleanup_command. But I still think the archive_cleanup_command/recovery_end_command functionality should eventually be added to recovery modules. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com