On Sat, Sep 4, 2010 at 5:02 AM, Josh Berkus <josh(at)agliodbs(dot)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?
And we would need to change primary_conninfo in all the unpromoted
standbys before restarting them.
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
In response to
pgsql-hackers by date
|Next:||From: Michael Haggerty||Date: 2010-09-06 02:59:18|
|Subject: Re: git: uh-oh|
|Previous:||From: Andrew Chernow||Date: 2010-09-05 23:56:42|
|Subject: Re: returning multiple result sets from a stored procedure|