Re: archive modules

On Wed, Sep 14, 2022 at 04:47:23PM -0400, Tom Lane wrote:
> Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)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 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().
>
> 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.

--
Nathan Bossart
Amazon Web Services: https://aws.amazon.com