On Wed, Sep 22, 2010 at 5:43 PM, Heikki Linnakangas
<heikki.linnakangas@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