On Fri, Sep 12, 2014 at 09:16:42PM +0900, Michael Paquier wrote:
> 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.
I like this. Can we apply it Heikki?
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ Everyone has their own god. +