Fujii, all,
* Fujii Masao (masao.fujii@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. In other words, why
not invent
XLogRecPtr newestReceviedUpto; /* or something */
and update that as necessary and have the function you want changed
return that, and leave receivedUpto alone..? It seems like it'd be a
lot easier to prove to ourselves that your patch didn't break anything,
presuming the function we're talking about changing the return value of
isn't called anywhere (seems rather unlikely to me..).
Also, you really should reformat the docs properly when you change them,
rather than leaving the lines ragged..
Thanks,
Stephen
