Hi,
Defending my ideas as not to be put in the bag you're wanting to put
away. We have more than 2 proposals lying around here. I'm one of the
guys with a proposal and no code, but still trying to be clear.
Robert Haas <robertmhaas@gmail.com> writes:
> The reason I think that we should centralize parameters on the master
> is because they affect *the behavior of the master*. Controlling
> whether the master will wait for the slave on the slave strikes me
> (and others) as spooky action at a distance.
I hope it's clear that I didn't propose anything like this in the
related threads. What you setup on the slave is related only to what the
slave has to offer to the master. What happens on the master wrt with
waiting etc is setup on the master, and is controlled per-transaction.
As my ideas come in good parts from understanding Simon work and
proposal, my feeling is that stating them here will help the thread.
> Configuring whether the
> master will retain WAL for a disconnected slave on the slave is
> outright byzantine.
Again, I can't remember having proposed such a thing.
> Of course, configuring these parameters on the
> master means that when the master changes, you're going to need a
> configuration (possibly the same, possibly different) for said
> parameters on the new master. But since you may be doing a lot of
> other adjustment at that point anyway (e.g. new base backups, changes
> in the set of synchronous slaves) that doesn't seem like a big deal.
Should we take some time and define the behaviors we expect in the
cluster, and the ones we want to provide in case of each error case we
can think about, we'd be able to define the set of parameters that we
need to operate the system.
Then, some of us are betting than it will be possible to accommodate
with either a unique central setup that you edit in only one place at
failover time, *or* that the best way to manage the setup is having it
distributed.
Granted, given how it currently works, it looks like you will have to
edit the primary_conninfo on a bunch of standbys at failover time, e.g.
I'd like that we now follow Josh Berkus (and some other) advice now, and
start a new thread to decide what we mean by synchronous replication,
what kind of normal behaviour we want and what responses to errors we
expect to be able to deal with in what (optional) ways.
Because the more we're staying on this thread, and the clearer it is
that there isn't two of us talking about the same synchronous
replication feature set.
Regards,
--
dim