Re: archive modules - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: archive modules
Date
Msg-id 20220914200305.GA2984249@nathanxps13
Whole thread Raw
In response to Re: archive modules  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: archive modules
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: why can't a table be part of the same publication as its schema
Next
From: Peter Eisentraut
Date:
Subject: Re: cataloguing NOT NULL constraints