On 23/09/10 20:03, Tom Lane wrote:
> Robert Haas<robertmhaas@gmail.com> writes:
>> On Thu, Sep 23, 2010 at 12:52 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
>>> Um ... so how does this standby know what master to connect to, what
>>> password to offer, etc? I don't think that "pass down parameters after
>>> connecting" is likely to cover anything but a small subset of the
>>> configuration problem.
>
>> Huh? We have that stuff already.
>
> Oh, I thought part of the objective here was to try to centralize that
> stuff. If we're assuming that slaves will still have local replication
> configuration files, then I think we should just add any necessary info
> to those files and drop this entire conversation. We're expending a
> tremendous amount of energy on something that won't make any real
> difference to the overall complexity of configuring a replication setup.
> AFAICS the only way you make a significant advance in usability is if
> you can centralize all the configuration information in some fashion.
If you want the behavior where the master doesn't acknowledge a commit
to the client until the standby (or all standbys, or one of them etc.)
acknowledges it, even if the standby is not currently connected, the
master needs to know what standby servers exist. *That's* why
synchronous replication needs a list of standby servers in the master.
If you're willing to downgrade to a mode where commit waits for
acknowledgment only from servers that are currently connected, then you
don't need any new configuration files. But that's not what I call
synchronous replication, it doesn't give you the guarantees that
textbook synchronous replication does.
(Gosh, I wish the terminology was more standardized in this area)
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com