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