On Sat, Sep 4, 2010 at 5:02 AM, Josh Berkus <josh@agliodbs.com> wrote:
> (a) seems easily enough solved by giving two steps: giving the DBA a way
> to check where in the replication stream each standby is (I think we
> already have this)
Yep, pg_last_xlog_receive_location would help.
> The second method would be by giving standbys a way to "subscribe" to a
> new timeline. This seems like the better approach, as it would
> logically be part of the re-mastering command. What changes would be
> required to do this?
Wait for new master to archive the timeline history file, set
recovery_target_timeline to 'latest' in unpromoted standbys and
restart them. Which would make them restore WAL files with previous
timeline from the archive and read WAL files with current one.
> (c) can actually already be dealt with by setting an archive_command on
> each standby. Beyond that, I don't think that we really need to do
> anything; DBAs can have a choice between archiving logs to allow for
> remastering of all standbys, or saving space and bandwidth, and forcing
> some standbys to be re-cloned if you run out of time. It would be nice,
> eventually, to have a way to tell PostgreSQL to retain more or less WAL
> segments without restarting the server, but I don't see this as critical.
Or the register/unregister of standbys facility is required?
http://archives.postgresql.org/pgsql-hackers/2010-08/msg01984.php
And we would need to change primary_conninfo in all the unpromoted
standbys before restarting them.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center