Synchronous replication
in [PgSql]
|
From: Fujii Masao on 5 Aug 2010 10:14 On Wed, Aug 4, 2010 at 10:38 PM, Heikki Linnakangas <heikki.linnakangas(a)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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |