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 1pAIzt-0005zm-QM for pgsql-hackers@arkaria.postgresql.org; Tue, 27 Dec 2022 23:04:37 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pAIzs-0003kp-Dw for pgsql-hackers@arkaria.postgresql.org; Tue, 27 Dec 2022 23:04:36 +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 1pAIzs-0003ke-1b for pgsql-hackers@lists.postgresql.org; Tue, 27 Dec 2022 23:04:36 +0000 Received: from mail-pj1-x102b.google.com ([2607:f8b0:4864:20::102b]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1pAIzp-0003Q6-CO for pgsql-hackers@postgresql.org; Tue, 27 Dec 2022 23:04:35 +0000 Received: by mail-pj1-x102b.google.com with SMTP id hd14-20020a17090b458e00b0021909875bccso15361382pjb.1 for ; Tue, 27 Dec 2022 15:04:32 -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=kpzdEakQVrbxyLNwow/Gu4JjWHNyh2aIjLvEA2E66LU=; b=oGJJ2i4FFH91x5qbkzFPlJ8gJYuY8UoY1iYi0YUVm3Aj+ZUTeXPqS+RyrIYMQSLLhq /NYwaJGLqDXx6+HJbFOU72WwkhVs7YXEUohsFobMX4mk2nPP7DUoB/5Zhegf3P8LQKns zwQ0itgnbJmjs05us6Wp/jP2V1PqQav/IgW1EdDCCzTkFs3DOrqJbCX7x2nHzUIVXRpZ dYJkV53btbe5ybibbLl7YJOhKO/TBwBkt95gbwAnXGbMRC1PU9eXKPoTdq377H4tIdi4 qZpIkHwJvkBA55qb2GzPBqA0fkdu3unXYrvmDaSSBobXkl6xWFFKWh2RZjOGyoM0JtZf 8Afw== 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=kpzdEakQVrbxyLNwow/Gu4JjWHNyh2aIjLvEA2E66LU=; b=ynnGPX1WmBRxwcwPxO5gP/4w3pPjMtfTrInaTn4l4LquxQ8skfCkSJ8PxLbh7CflYA Rud89Ew6UcFn1aOxHVuJ4F49edj/KvqNY4IrEW7PFx/VCvQjfUGWOK9MK/xhrREwMoYH TNHIKqobUIrqUG2rTNTgexOpZ8H3aaNvtVahiJOvE7gyZECtxXa6aPKbRdejoU/XcNDN Gktrnsw8fpcDB03uhenp+rrJ3JOl1bAdRS3ibc5KdJ78maK78dURSxcryJDnIluBZtbP bXNk4LDZXhOEYB/GZs9RHo6veWqmzod4EtBLx61bz5MsWesfREqt8ebh9TZXRnTdBN9o KJ3A== X-Gm-Message-State: AFqh2kqAljFh5WtRa649OzLbv9S7llDbJRd0Pk070XmCLyOdA9zHVAPE wAHPRfrW0kn2ltYvyMtO+0eUssk6G1c= X-Google-Smtp-Source: AMrXdXtkHHx6RFNfXerD0FPtRlmAKLeW8CaUxVZaxYrVKxHKVL2N32EIYHbLa4dPqof5+Ok8j4wWkw== X-Received: by 2002:a05:6a20:4995:b0:aa:7eab:25a5 with SMTP id fs21-20020a056a20499500b000aa7eab25a5mr26308362pzb.34.1672182271087; Tue, 27 Dec 2022 15:04:31 -0800 (PST) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id 135-20020a62148d000000b00580849b55a2sm8207424pfu.26.2022.12.27.15.04.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 27 Dec 2022 15:04:30 -0800 (PST) Date: Tue, 27 Dec 2022 15:04:28 -0800 From: Nathan Bossart To: Andres Freund Cc: pgsql-hackers@postgresql.org Subject: Re: recovery modules Message-ID: <20221227230428.GA3780529@nathanxps13> References: <20221227192449.GA3672473@nathanxps13> <20221227221111.xjw5hc3fqzt773gu@awork3.anarazel.de> <20221227223711.GA3779714@nathanxps13> <20221227224530.uh4t62hryidwxeva@awork3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221227224530.uh4t62hryidwxeva@awork3.anarazel.de> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Dec 27, 2022 at 02:45:30PM -0800, Andres Freund wrote: > On 2022-12-27 14:37:11 -0800, Nathan Bossart wrote: >> On Tue, Dec 27, 2022 at 02:11:11PM -0800, Andres Freund wrote: >> > On 2022-12-27 11:24:49 -0800, Nathan Bossart wrote: >> >> * pg_rewind uses restore_command, but there isn't a straightforward path to >> >> support restore_library. I haven't addressed this in the attached patches, >> >> but perhaps this is a reason to allow specifying both restore_command and >> >> restore_library at the same time. pg_rewind would use restore_command, and >> >> the server would use restore_library. >> > >> > That seems problematic, leading to situations where one might not be able to >> > use restore_command anymore, because it's not feasible to do >> > segment-by-segment restoration. >> >> I'm not following why this would make segment-by-segment restoration >> infeasible. Would you mind elaborating? > > Latency effects for example can make it infeasible to do segment-by-segment > restoration infeasible performance wise. On the most extreme end, imagine WAL > archived to tape or such. I'm sorry, I'm still lost here. Wouldn't restoration via library tend to improve latency? Is your point that clusters may end up depending on this improvement so much that a shell command would no longer be able to keep up? I might be creating a straw man, but this seems like less of a concern for pg_rewind since it isn't meant for continuous, ongoing restoration. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com