On Fri, Feb 11, 2011 at 12:25 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Feb 11, 2011 at 11:52 AM, Stephen Frost <sfr...@snowman.net> wrote: >> Fujii, all, >> >> * Fujii Masao (masao.fu...@gmail.com) wrote: >>> That logic exists because we'd like to check that newly-received WAL >>> data is consistent with previous one by validating the header of new >>> WAL file. So since we need the header of new WAL file, we retreat the >>> replication starting location to the beginning of the WAL file when >>> reconnecting to the primary. >> >> Thanks for that explanation, but I can't help but wonder why it doesn't >> make more sense to introduce a new variable to track the value you want >> rather than reusing an existing one and then adding a variable to >> represent what the old variable was already doing. > > +1. > > It seems like there may be some more significant changes in this area > needed; however, for now I think the best fix is the one with the > least chance of breaking anything.
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. -- 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
