On Wed, Sep 22, 2010 at 5:43 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > So let's put synchronous replication aside for now, and focus on standby > registration first. Once we have that, the synchronous replication patch > will be much smaller and easier to review.
Though I agree with standby registration, I'm still unclear what's standby registration ;) What if the number of standby entries in standby.conf is more than max_wal_senders? This situation is allowed if we treat standby.conf as just access control list like pg_hba.conf. But if we have to ensure that all the registered standbys can connect to the master, we should emit the error in that case. Should we allow standby.conf to be changed and reloaded while the server is running? This seems to be required if we use standby.conf for replacement of wal_keep_segments. Because we need to register the backup starting location as the last receive location of upcoming standby when taking a base backup for that standby. But what if the reloaded standby.conf has no entry for already connected standby? If we treat standby.conf as just access control list, we can easily allow it to be reloaded as well as pg_hba.conf is. Otherwise, we would need a careful design. Should we allow multiple standbys with the same name to connect to the master? That is, entry in standby.conf and real standby should be one-to-one relationship? Or we should add new parameter specifying the number of standbys with the name? > Any volunteers on implementing that? Fujii-san? I'm willing to implement that. But I'll be busy for a few days because of presentation at LinuxCon and so on. So please feel free to try that if time allows. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
