On Fri, Feb 11, 2011 at 12:52 PM, Stephen Frost <sfr...@snowman.net> wrote: > * 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?
It'll restream the whole segment up to wherever it was, but basically, yes. I think a big part of the problem here is that we have wildly inconsistent terminology for no especially good reason. The standby reports three XLOG positions to the master, currently called write, flush, and apply. The walreceiver reports positions called recievedUpTo and lastChunkStart. receivedUpTo is actually the FLUSH position, and lastChunkStart is the previous flush position, except when the walreceiver first starts, when it's the position at which streaming is to begin. So, what if we did some renaming? I'd be inclined to start by renaming "receivedUpTo" to Flush, and add a new position called Stream. When walreciever is started, we set Stream to the position at which streaming is going to begin (which can rewind) and leave Flush alone (so it never rewinds). We then change the walreceiver feedback mechanism to use the term stream_location rather than write_location; and we could consider replacing pg_last_xlog_receive_location() with pg_last_xlog_stream_location() and pg_last_xlog_flush_location(). That's a backward compatibility break, but maybe it's worth it for the sake of terminological consistency, not to mention accuracy. I'd also be inclined to go to the walreceiver code and and rename the apply_location to replay_location, so that it matches pg_last_xlog_replay_location(). The latter is in 9.0, but the former is new to 9.1, so we can still fix it to be consistent without a backward compatibility break. Thoughts, comments? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers