On 22/09/10 16:54, Robert Haas wrote:
On Wed, Sep 22, 2010 at 8:21 AM, Fujii Masao<masao.fu...@gmail.com> wrote:
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.
I don't think a cross-check between these settings makes much sense.
We should either get rid of max_wal_senders and make it always equal
to the number of defined standbys, or we should treat them as
independent settings.
Even with registration, we will continue to support anonymous
asynchronous standbys that just connect and start streaming. We need
some headroom for those.
But what if the
reloaded standby.conf has no entry for already connected standby?
We kick him out?
Sounds reasonable.
Should we allow multiple standbys with the same name to connect to
the master?
No. The point of naming them is to uniquely identify them.
Hmm, that situation can arise if there's a network glitch which leads
the standby to disconnect, but the master still considers the connection
as alive. When the standby reconnects, the master will see two
simultaneous connections from the same standby. In that scenario, you
clearly want to disconnect the old connetion in favor of the new one. Is
there a scenario where you'd want to keep the old connection instead and
refuse the new one?
Perhaps that should be made configurable, so that you wouldn't need to
list all standbys in the config file if you don't want to. Then you
don't get any of the benefits of standby registration, though.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
