Re: The other major HS TODO: standby promotion

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