From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
cc: Nathan Bossart <nathandbossart@gmail.com>,
        =?UTF-8?Q?Benoit_Lobr=c3=a9au?= <benoit.lobreau@gmail.com>,
        Alvaro Herrera <alvherre@alvh.no-ip.org>,
        Robert Haas <robertmhaas@gmail.com>,
        "Bossart,
    Nathan" <bossartn@amazon.com>,
        David Steele <david@pgmasters.net>,
        Fujii Masao <masao.fujii@oss.nttdata.com>,
        "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
        Michael Paquier <michael@paquier.xyz>,
        Magnus Hagander <magnus@hagander.net>,
        Stephen Frost <sfrost@snowman.net>
Subject: Re: archive modules
In-reply-to: <37857474-5caa-ccb3-92a3-150ddfe851ab@enterprisedb.com>
References: 
 <CAPE8EZ7vh6gdgHjAYhuvjUJzvZm7PGeZQaDDBfSYmDmfa+QeFg@mail.gmail.com>
 <20220824221723.GA1347845@nathanxps13>
 <CAPE8EZ4F3d06diQ27D=5qxN2FVHA0qsaRghzkLDf=KZHEUN7rg@mail.gmail.com>
 <20220825200600.GA1465148@nathanxps13> <20220829224621.GB541895@nathanxps13>
 <CAPE8EZ7SQKKkreVT2Cjrheg8dChT_qSDRBS71r-r+girEMQ4bw@mail.gmail.com>
 <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>
Comments: In-reply-to Peter Eisentraut <peter.eisentraut@enterprisedb.com>
	message dated "Wed, 14 Sep 2022 22:07:11 +0200"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2884264.1663188443.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 14 Sep 2022 16:47:23 -0400
Message-ID: <2884265.1663188443@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2884265.1663188443%40sss.pgh.pa.us>
Precedence: bulk

Peter Eisentraut <peter.eisentraut@enterprisedb.com> 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 assi=
gn
>> * hook breaks fundamental assumptions of guc.c.  So long as all the var=
iables
>> * for which this can happen are PGC_POSTMASTER, the consequences are li=
mited,
>> * since we'd just abort postmaster startup anyway.  Nonetheless it's li=
kely
>> * that we have odd behaviors such as unexpected GUC ordering dependenci=
es.

> 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.

			regards, tom lane