* Robert Haas (robertmh...@gmail.com) wrote: > Actually... wait a minute. Now that I'm thinking about this a little > more, I'm not so convinced. If we leave this the way is, and just > paper over the problem using the method Stephen and I both had in > mind, then we could be streaming from a position that precedes the > so-called "current" position. And worse, the newly introduced replies > to the master will still show the position going backward, so the > master will reflect a position that is earlier that the position the > slave reports for itself, not because of any real difference but > because of a reporting difference. That sure doesn't seem good.
I'm really not sure it's as bad as all that... The slave and the master
are only going to be "out of sync" wrt position until the slave sends
the request for update to the master, gets back the result, and checks
the XLOG header, right?
Here's my question- we're talking about if the master dies here, as I
understand it. If the slave comes up and can't get to the master, is he
going to be reporting the older position, or his current one? The
answer to that should be, I believe, the *current* one. He'd only "go
backwards" *if* the master is up and he gets his request over to the
master to get the old log. In fact, if he comes up and gets his request
off to the master and the master never replies, in my view, he should be
able to be restarted into 'master' mode and come all the way up to
'current' (which would be later than what he was trying to ask the
master for). *That* is the value, I think, that Fujii is looking for-
if this slave started up as a master, where would he be? That should
always be increasing. The fact that we "back up" a little, as a
double-check to make sure we didn't get wildly out of sync, and because
we want the master to only be producing full XLOGs, is an implementation
detail, really, that probably doesn't really need to be exposed..
That may mean that we want to change what the slave is reporting for
itself though, if it's currently allowed to be seen "going backwards",
but I don't think that would be terribly difficult to change...
I havn't really dug into the SR/HS stuff, so I could be way off too..
Thanks,
Stephen
signature.asc
Description: Digital signature
