On Fri, Oct 18, 2013 at 1:13 PM, Jaime Casanova <ja...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
