Re: archive modules
От | Nathan Bossart |
---|---|
Тема | Re: archive modules |
Дата | |
Msg-id | 20220914222736.GA3042279@nathanxps13 обсуждение исходный текст |
Ответ на | Re: archive modules (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: archive modules
|
Список | pgsql-hackers |
On Wed, Sep 14, 2022 at 06:12:09PM -0400, Tom Lane wrote: > 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. Both archive_command and archive_library are PGC_SIGHUP, so IIUC that wouldn't be sufficient. I attached a quick sketch that seems to provide the desired behavior. It's nowhere near committable yet, but it demonstrates what I'm thinking. For recovery_target_*, something like you are describing seems reasonable. I believe PostmasterMain() already performs some similar checks. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
Вложения
В списке pgsql-hackers по дате отправления: