On Fri, Sep 12, 2014 at 4:55 PM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> I haven't looked at those places closely, but it seems possible that at
> least some of those variables are supposed to be initialized to a value
> smaller than any valid WAL position, rather than just Invalid. In other
> words, if we defined InvalidXLogRecPtr as INT64_MAX rather than 0, we would
> still want those variables to be initialized to zero. As I said, I didn't
> check the code, but before we change those that ought to be checked.
Ah, OK. I just had a look at that, and receivedUpto and lastComplaint
in xlog.c need to use the lowest pointer value possible as they do a
couple of comparisons with other positions. This is as well the case
of sentPtr in walsender.c. However, that's not the case of writePtr
and flushPtr in walreceiver.c as those positions are just used for
direct comparison with LogstreamResult, so we could use
InvalidXLogRecPtr in this case.
What do you think of the addition of a #define for the lowest possible
XLOG location pointer? I've wanted that as well a couple of times when
working on clients using replication connections for for example
START_REPLICATION. That would be better than hardcoding a position
like '0/0', and would make the current code more solid.
Patch attached in case.
Regards,
--
Michael
