On Fri, Sep 12, 2014 at 09:16:42PM +0900, Michael Paquier wrote: > On Fri, Sep 12, 2014 at 4:55 PM, Heikki Linnakangas > <hlinnakan...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers