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 1oYYbL-0002OQ-Oz for pgsql-hackers@arkaria.postgresql.org; Wed, 14 Sep 2022 20:03:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oYYbK-0003Md-1M for pgsql-hackers@arkaria.postgresql.org; Wed, 14 Sep 2022 20:03:14 +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 1oYYbJ-0003MU-ND for pgsql-hackers@lists.postgresql.org; Wed, 14 Sep 2022 20:03:13 +0000 Received: from mail-pl1-x62a.google.com ([2607:f8b0:4864:20::62a]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oYYbH-0001om-9l for pgsql-hackers@postgresql.org; Wed, 14 Sep 2022 20:03:12 +0000 Received: by mail-pl1-x62a.google.com with SMTP id x1so16216931plv.5 for ; Wed, 14 Sep 2022 13:03:11 -0700 (PDT) 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; bh=hrK9vIfP77sfmQTSls950fVbxxGTpYw/ZYVIIn7j+uk=; b=eDO6no+YYKK8d3Wj5HXuhtjNG7VIKwyl1YIjrKCG2olMCtKUqMwzgDFZrxrYBB4YH4 8u7MeIwDGzypIeUDoNq9Llcnr9pfqnQ/EKaI+//abK3+DQcX6GTaimwwi4txxE5OK+ha 5OnVBa9C45YU3dDD1nSzge8YYXrMxpZHcsCba2oOVbRF2ueqjtvsVBS+v7xVwcu+QKB/ IujJPNx+WSxoNVkk2wTcFFZucEoiLjwCOOUizLwMdR7vZrDuDg2uLZOTAiyeVmTiIL8+ VG09Ao/MU+f1aBonebcoVBMNrpcPzBv5L2AlheIkiDb/7kXPWujDy6PUvPXJTF+4d562 qTAg== 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; bh=hrK9vIfP77sfmQTSls950fVbxxGTpYw/ZYVIIn7j+uk=; b=hQrALiQoTLkRx9Lrc5FdRugPvg1fM0AYo6aQtPrPd3y7tjqnbv1Yn0CqxBOBvvASL7 pEPPcgI0VimV0j+V7ULPCRvu+5L/bcJwAk8uoOArcR/LmJReVkI8U62hPkwBqD6fbUqu j4aCW/iAvXLeJC8M1qa2H2Gq7DmZymvrvkjnEcyb1qt7zUjRGw51s9kLkBLsLDbr7VFi 6gLEN0ftl8JoqyRDpdS/g9JYxCQh+3jzxHEvTmvaHvhTZcY4RyXDfsinqX0KBVlUIMNz GRoXXtEEn5+d/NYzoeEyXy7ODm1au70mqpX3NnnJBiFYgJ9nSVSw6O3DFhE9xl2vdLQ4 M9gw== X-Gm-Message-State: ACrzQf2+67uXVR5qW3fZlfCrV+vxZDwpzZWTZTbJEgm/Yoe+RmWr2Dee HNXoJqHAbfZdaO9omzfjd6E= X-Google-Smtp-Source: AMsMyM6PIAzJJDevZMSwRlMuFmVcF5WsXpMRfNk72lfIdTkzmynWYTrYjieNRBvvjR9q/zZdNAW50w== X-Received: by 2002:a17:90b:4b43:b0:202:e09c:664d with SMTP id mi3-20020a17090b4b4300b00202e09c664dmr6534776pjb.120.1663185790148; Wed, 14 Sep 2022 13:03:10 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id x2-20020a17090aa38200b001fd77933fb3sm36927pjp.17.2022.09.14.13.03.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Sep 2022 13:03:08 -0700 (PDT) Date: Wed, 14 Sep 2022 13:03:05 -0700 From: Nathan Bossart To: Peter Eisentraut Cc: Tom Lane , Benoit =?iso-8859-1?Q?Lobr=E9au?= , Alvaro Herrera , Robert Haas , "Bossart, Nathan" , David Steele , Fujii Masao , "pgsql-hackers@postgresql.org" , Michael Paquier , Magnus Hagander , Stephen Frost Subject: Re: archive modules Message-ID: <20220914200305.GA2984249@nathanxps13> References: <20220824221723.GA1347845@nathanxps13> <20220825200600.GA1465148@nathanxps13> <20220829224621.GB541895@nathanxps13> <20220830163048.GA544233@nathanxps13> <613541.1662842656@sss.pgh.pa.us> <20220910211046.GA2651323@nathanxps13> <9ee5d180-2c32-a1ca-d3d7-63a723f68d9a@enterprisedb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9ee5d180-2c32-a1ca-d3d7-63a723f68d9a@enterprisedb.com> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Sep 14, 2022 at 09:33:46PM +0200, Peter Eisentraut wrote: > Another question on this feature: Currently, if archive_library is set, > archive_command is ignored. I think if both are set, it should be an error. > Compare for example what happens if you set multiple recovery_target_xxx > settings. I don't think silently turning off one setting by setting another > is a good behavior. I originally did it this way, but changed it based on this feedback [0]. I have no problem with the general idea, but the recovery_target_* logic does have the following note: * XXX this code is broken by design. Throwing an error from a GUC assign * hook breaks fundamental assumptions of guc.c. So long as all the variables * for which this can happen are PGC_POSTMASTER, the consequences are limited, * since we'd just abort postmaster startup anyway. Nonetheless it's likely * that we have odd behaviors such as unexpected GUC ordering dependencies. [0] https://postgr.es/m/CA%2BTgmoaf4Y7_U%2B_W%2BSg5DoAta_FMssr%3D52mx7-_tJnfaD1VubQ%40mail.gmail.com -- Nathan Bossart Amazon Web Services: https://aws.amazon.com