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 1oYZld-0002kg-57 for pgsql-hackers@arkaria.postgresql.org; Wed, 14 Sep 2022 21:17:57 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oYZlb-0002GT-5B for pgsql-hackers@arkaria.postgresql.org; Wed, 14 Sep 2022 21:17:55 +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 1oYZla-0002GK-Q8 for pgsql-hackers@lists.postgresql.org; Wed, 14 Sep 2022 21:17:54 +0000 Received: from mail-pf1-x429.google.com ([2607:f8b0:4864:20::429]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oYZlY-0002N7-BF for pgsql-hackers@postgresql.org; Wed, 14 Sep 2022 21:17:53 +0000 Received: by mail-pf1-x429.google.com with SMTP id 9so5012682pfz.12 for ; Wed, 14 Sep 2022 14:17:52 -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=BY0eoKOZuUijXpMQdVyCEsbptA16Z+pv+DKo75cMrNc=; b=NmwGI06xtateFbVgPenHkbRIOUuQuBkeD7muDWf5whP5VgFYDPj5RnIw/wieppEj0G jUIZ8Lmc2R6qWcX534+LhS9vczRmWl1bksLctP2iTllK3Gded/Nul5ih4PDQij5a+8Mm YasfEjv2JncaJV+Z8lj6psITwg11bW27HwyU3u13IjcCeZ46iVChuCupKowXszE/2Yzw WXoEv7MMoiyWmpa/jGbF2JMOG94vPCxIZXFxBL+v9FwfIr6aZItfXtGSH1sAgWXMuEtM z8y4gZUBXIqYFuEoD9Hmt4HKlTRe02uMES/FJ+O87fWbjfflKNV1baN8bhftYQhIZSjB XqBg== 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=BY0eoKOZuUijXpMQdVyCEsbptA16Z+pv+DKo75cMrNc=; b=JG112rZYpWhN81kLjM2+byvQTYtJMsjWFSWk57TUNc+qefhIP4JW/O2ZTikMmUByqf kcpvaiGmX/90MDLCuZNQjwedX8Q5X1bz+jrXCOl53s2Uza10mVXOBba2MN8Wp5mK6jQm epqfxC6X/4dKhe7KW2qtZGLn7v2Bpm48MKS3I8YJF58PN+zKDB4B+Uwng4PNJj7OdlqJ YkC6NzOJTykIIergUYXIwdYXlGV2DxJqTroh5p8Yft0xz/YbIueSAH6zgId+aUUwK7xh HFzcdX00Wmrzif5n0l/14stwXO676re4rKh0AwG+19mg6hoYYTRtGyWTtxPBI5wMb2fl tfNQ== X-Gm-Message-State: ACgBeo02f2ftf7nEZQHnTNvjoGDpIqC0Ftt3M7ipEUzpIejfaHJ/fTUz dRAMb3fsPLGs7NJoLljH9Mk= X-Google-Smtp-Source: AA6agR5BK7+1jC02jQ5g2+cjYUrirttlCjImPIfOO2PAlDTU2y/d8b64jZq2/ZGOYnTYZlhWQ5Js6A== X-Received: by 2002:a63:1f12:0:b0:438:fa5b:ff76 with SMTP id f18-20020a631f12000000b00438fa5bff76mr14857895pgf.390.1663190271423; Wed, 14 Sep 2022 14:17:51 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id y75-20020a62644e000000b005365aee486bsm10589064pfb.192.2022.09.14.14.17.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 14 Sep 2022 14:17:50 -0700 (PDT) Date: Wed, 14 Sep 2022 14:17:46 -0700 From: Nathan Bossart To: Tom Lane Cc: Peter Eisentraut , 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: <20220914211746.GA2986134@nathanxps13> References: <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> <20220914200305.GA2984249@nathanxps13> <37857474-5caa-ccb3-92a3-150ddfe851ab@enterprisedb.com> <2884265.1663188443@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2884265.1663188443@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Sep 14, 2022 at 04:47:23PM -0400, Tom Lane wrote: > Peter Eisentraut writes: >> On 14.09.22 22:03, Nathan Bossart wrote: >>> 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. > >> Ah yes, that won't work. But maybe we can just check it at run time, >> like in LoadArchiveLibrary(). > > Yeah, the objection there is only to trying to enforce such > interrelationships in GUC hooks. In this case it seems to me that > we could easily check and complain at the point where we're about > to use the GUC values. I think the cleanest way to do something like that would be to load a check_configured_cb that produces a WARNING. IIRC failing in LoadArchiveLibrary() would just cause the archiver process to restart over and over. HandlePgArchInterrupts() might need some work as well. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com