Fujii Masao wrote:
> On Wed, Aug 4, 2010 at 10:38 PM, Heikki Linnakangas
> <heikki.linnakan...@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())
I know there has been discussion about how to identify the standby
servers --- how about using the connection application_name in
recovery.conf:
primary_conninfo = 'host=localhost port=5432 application_name=slave1'
The good part is that once recovery.conf goes away because it isn't a
standby anymore, the the application_name is gone.
An even more interesting approach would be to specify the replication
mode in the application_name:
primary_conninfo = 'host=localhost port=5432 application_name=replay'
and imagine being able to view the status of standby servers from
pg_stat_activity. (Right now standby servers do not appear in
pg_stat_activity.)
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
