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 1oj2sR-0000j7-N9 for pgsql-hackers@arkaria.postgresql.org; Thu, 13 Oct 2022 18:24: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 1oj2sQ-0007SO-FH for pgsql-hackers@arkaria.postgresql.org; Thu, 13 Oct 2022 18:24: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 1oj2sQ-0007SF-3U for pgsql-hackers@lists.postgresql.org; Thu, 13 Oct 2022 18:24:14 +0000 Received: from mail-pl1-x62e.google.com ([2607:f8b0:4864:20::62e]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oj2sN-0008My-Iy for pgsql-hackers@postgresql.org; Thu, 13 Oct 2022 18:24:13 +0000 Received: by mail-pl1-x62e.google.com with SMTP id n7so2580168plp.1 for ; Thu, 13 Oct 2022 11:24: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:message-id:reply-to; bh=bvFkepn1CLCnBVhsyPAMnlqchqfW92Q8dq5s29rTaRM=; b=TqXukYUpYYOzAfBdTpp3BP8X/x8o/wNOohj+UoZ5MWDvN9wOvuXvPmy0yaoMynAlDU tZmk3AgecPMFKiOco7WjpjAJCszZP0uN584Y/Oj0LmnBOce/C3wtWp/EV4g0tqehLNwX VGc92qZJ51CyIYYelp38eONrvcv0HZdfBCTqYCde1y6h8YctEnPyQTwUIkq0MlY9H0iN f3VrC2ncKoU30FLVPhDdMq+tPVugIySxamK3PWnTMLaV3XgVY+vOMHqjWr4mMTNQdq3r /v/rt55hUjlAFLHrBJ9GhcOjsf67hv7dR7LBLQ54oWnpQ2Uc2Yij50hY5+fGMyrrKTfU Ys1g== 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=bvFkepn1CLCnBVhsyPAMnlqchqfW92Q8dq5s29rTaRM=; b=Jv6E9VbxAV+BYlR+J4KwOUgH/5SGIdEbV6PvjnIWF6xUNOhjsTZ8wkiHaX2Ks0XIHz ljxVwqDFRN8CX2shhJXsGMOrfR5S2gizPW6KClP54/XbJYA5d75sFmRbZ9rkk1RkhWQ1 kS2+q65/1aaMuWJZAgN8RLe17ndzzzD52rLDHuv/d55MMAJNpua8q4nF8WieOPOdH4Zp k87+JbGLuY2noXgJmKFhSi3mVMR3/8wqVukmJHQCxEtYVMBwd0+/JeiZjdDK14L5XmP9 2QtfGuFvnmg12wxwPumrKjDZB+Xra/Xg5Cxko8kdROFUChT+3bPG1Z9GnENj+Q5u4Q/l MUcA== X-Gm-Message-State: ACrzQf3I1Na8NZAMoWkhhMiB3raX9DQZZkxpDNBlh739dNpXXpk2zop7 xhMY+lKbTQT4uJfEnUlTzQk= X-Google-Smtp-Source: AMsMyM7C+n0DwgNRSPQTmA54BtwZs2WWQORPnnc7z8sQ11NyFFBMvFXZO5FkxbQ8lOL+gtQoDRGXMg== X-Received: by 2002:a17:90b:1c8d:b0:203:cc25:4eb5 with SMTP id oo13-20020a17090b1c8d00b00203cc254eb5mr1200502pjb.132.1665685450629; Thu, 13 Oct 2022 11:24:10 -0700 (PDT) Received: from nathanxps13 ([50.47.162.83]) by smtp.gmail.com with ESMTPSA id h5-20020a628305000000b00562a90f9875sm8768pfe.167.2022.10.13.11.24.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 13 Oct 2022 11:24:09 -0700 (PDT) Date: Thu, 13 Oct 2022 11:24:08 -0700 From: Nathan Bossart To: Bharath Rupireddy Cc: Peter Eisentraut , 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: <20221013182408.GA1551106@nathanxps13> References: <2884265.1663188443@sss.pgh.pa.us> <20220914211746.GA2986134@nathanxps13> <2910705.1663193529@sss.pgh.pa.us> <20220914222736.GA3042279@nathanxps13> <20220923161402.GA736566@nathanxps13> <4f66de67-35a0-3fe7-fa61-d618e1bd2c2c@enterprisedb.com> <20221005185716.GB201192@nathanxps13> <1d9cb989-91b0-919e-f42b-4788f5fc7911@enterprisedb.com> 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 Thu, Oct 13, 2022 at 03:25:27PM +0530, Bharath Rupireddy wrote: > The intent here looks reasonable to me. However, why should the user > be able to set both archive_command and archive_library in the first > place only to later fail in LoadArchiveLibrary() per the patch? IMO, > the check_hook() is the right way to disallow any sorts of GUC > misconfigurations, no? There was some discussion upthread about using the GUC hooks to enforce this [0]. In general, it doesn't seem to be a recommended practice. One basic example of the problems with this approach is the following: 1. Set archive_command and leave archive_library unset and restart the server. 2. Unset archive_command and set archive_library and call 'pg_ctl reload'. After these steps, you'll see the following log messages: 2022-10-13 10:58:42.112 PDT [1562524] LOG: received SIGHUP, reloading configuration files 2022-10-13 10:58:42.114 PDT [1562524] LOG: cannot set "archive_library" when "archive_command" is specified 2022-10-13 10:58:42.114 PDT [1562524] DETAIL: Only one of "archive_library" or "archive_command" can be specified. 2022-10-13 10:58:42.114 PDT [1562524] LOG: parameter "archive_command" changed to "" 2022-10-13 10:58:42.114 PDT [1562524] LOG: configuration file "/home/nathan/pgdata/postgresql.conf" contains errors; unaffected changes were applied [0] https://postgr.es/m/20220914200305.GA2984249%40nathanxps13 -- Nathan Bossart Amazon Web Services: https://aws.amazon.com