On 23/09/10 20:03, Tom Lane wrote:
Robert Haas<robertmh...@gmail.com> writes:
On Thu, Sep 23, 2010 at 12:52 PM, Tom Lane<t...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
