Re: archive modules - Mailing list pgsql-hackers

From Tom Lane
Subject Re: archive modules
Date
Msg-id 2910705.1663193529@sss.pgh.pa.us
Whole thread Raw
In response to Re: archive modules  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: archive modules
List pgsql-hackers
Nathan Bossart <nathandbossart@gmail.com> writes:
> On Wed, Sep 14, 2022 at 04:47:23PM -0400, Tom Lane wrote:
>> 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.

Hm.  Maybe consistency-check these settings in the postmaster, sometime
after we've absorbed all GUC settings but before we launch any children?
That could provide a saner implementation for the recovery_target_*
variables too.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Sandro Santilli
Date:
Subject: Re: [PATCH] Support % wildcard in extension upgrade filenames
Next
From: Nathan Bossart
Date:
Subject: Re: archive modules