Re: archive modules - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: archive modules
Date
Msg-id 37857474-5caa-ccb3-92a3-150ddfe851ab@enterprisedb.com
Whole thread Raw
In response to Re: archive modules  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: archive modules
List pgsql-hackers
On 14.09.22 22:03, Nathan Bossart wrote:
> 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.

Ah yes, that won't work.  But maybe we can just check it at run time, 
like in LoadArchiveLibrary().




pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: cataloguing NOT NULL constraints
Next
From: Tom Lane
Date:
Subject: Re: archive modules