Re: Turning recovery.conf into GUCs
От | Michael Paquier |
---|---|
Тема | Re: Turning recovery.conf into GUCs |
Дата | |
Msg-id | CAB7nPqQ98pz=1_FXEgJZNx2QXTn9VO2bQU+RiS-0e6G=kGwKrg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Turning recovery.conf into GUCs (Jaime Casanova <jaime@2ndquadrant.com>) |
Список | pgsql-hackers |
On Fri, Oct 18, 2013 at 1:13 PM, Jaime Casanova <jaime@2ndquadrant.com> wrote: >>> = Code & functionality = >> >>> + {"restore_command", PGC_POSTMASTER, WAL_ARCHIVE_RECOVERY, >>> + {"archive_cleanup_command", PGC_POSTMASTER, WAL_ARCHIVE_RECOVERY, >>> + {"recovery_end_command", PGC_POSTMASTER, WAL_ARCHIVE_RECOVERY, >>> + {"recovery_target_xid", PGC_POSTMASTER, WAL_RECOVERY_TARGET, >>> + {"recovery_target_name", PGC_POSTMASTER, WAL_RECOVERY_TARGET, >>> + {"recovery_target_time", PGC_POSTMASTER, WAL_RECOVERY_TARGET, >>> + {"trigger_file", PGC_POSTMASTER, REPLICATION_STANDBY, >>> >>> Not sure about these ones >>> >>> + {"recovery_target_timeline", PGC_POSTMASTER, WAL_RECOVERY_TARGET, >>> + {"primary_conninfo", PGC_POSTMASTER, REPLICATION_STANDBY, >> >> It would be really nice to change these on the fly; it would help a lot >> of issues with minor changes to replication config. I can understand, >> though, that the replication code might not be prepared for that. >> > > well, archive_command can be changed right now with a SIGHUP so at > least that one shouldn't change... and i don't think most of these are > too different. even if we are not sure we can do this now and change > them as SIGHUP later Changing those parameters don't really matter as long as the node is not performing a recovery IMO, but I'd rather see a careful approach here and let all those parameters as PGC_POSTMASTER for now to avoid any surprises. Perhaps a second patch on top of this one could be the addition of context name like SIGHUP_RECOVERY, aka just allow those parameters to be updated with SIGHUP as long as the node is not in recovery. -- Michael
В списке pgsql-hackers по дате отправления: