On Wed, Aug 4, 2010 at 10:38 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> Then you risk running out of disk space. Similar to having an archive
> command that fails for some reason.
>
> That's one reason the registration should not be too automatic - there is
> serious repercussions if the standby just disappears. If the standby is a
> synchronous one, the master will stop committing or delay acknowledging
> commits, depending on the configuration, and the master needs to keep extra
> WAL around.
Umm... in addition to registration of each standby, I think we should allow
users to set the upper limit of the number of WAL files kept in pg_xlog to
avoid running out of disk space. If it exceeds the upper limit, the master
disconnects too old standbys from the cluster and removes all the WAL files
not required for current connected standbys. If you don't want any standby
to disappear unexpectedly because of the upper limit, you can set it to 0
(= no limit).
I'm thinking to make users register and unregister each standbys via SQL
functions like register_standby() and unregister_standby():
void register_standby(standby_name text, streaming_start_lsn text) void unregister_standby(standby_name text)
Note that standby_name should be specified in recovery.conf of each standby.
By using them we can easily specify which WAL files are unremovable because
of new standby when taking the base backup for it as follows:
SELECT register_standby('foo', pg_start_backup())
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center