Re: archive modules - Mailing list pgsql-hackers

From Tom Lane
Subject Re: archive modules
Date
Msg-id 2884265.1663188443@sss.pgh.pa.us
Whole thread Raw
In response to Re: archive modules  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: archive modules
List pgsql-hackers
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 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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: archive modules
Next
From: Nathan Bossart
Date:
Subject: Re: archive modules