On Wed, Sep 22, 2010 at 10:19 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
>> 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.
+1 for making that the behavior.
> Is there a scenario
> where you'd want to keep the old connection instead and refuse the new one?
I doubt it.
> 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.
I think it's fine to have async slaves that don't want any special
features (like sync rep, or tracking how far behind they are in the
xlog stream) not mentioned in the config file. But allowing multiple
slaves with the same name seems like complexity without any attendant
benefit.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company