On Sat, Sep 4, 2010 at 5:02 AM, Josh Berkus <j...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
