Re: SSI patch version 14

Kevin Grittner <kevin.grittner@wicourts.gov>

From: "Kevin Grittner" <Kevin.Grittner@wicourts.gov>
To: "Dan Ports" <drkp@csail.mit.edu>, "Heikki Linnakangas" <heikki.linnakangas@enterprisedb.com>
Cc: <simon@2ndQuadrant.com>,<markus@bluegap.ch>, <pgsql-hackers@postgresql.org>
Date: 2011-02-08T15:50:05Z
Lists: pgsql-hackers

Attachments

Dan Ports <drkp@csail.mit.edu> wrote: 
> On Tue, Feb 08, 2011 at 11:25:34AM +0200, Heikki Linnakangas
wrote:
>> On 08.02.2011 10:43, Kevin Grittner wrote:
>>> I see that at least three BuildFarm critters don't have
>>> UINT64_MAX defined.
>> 
>> I guess we'll have to just #define it ourselves. Or could we just
>> pick another magic value, do we actually rely on
>> InvalidSerCommitSeqno being higher than all other values
>> anywhere?
> 
> As far as I know we don't specifically rely on that anywhere, and
> indeed I did have it #defined to 1 at one point (with the other
> constants adjusted to match) and I don't recall any problems. But
> given that we most often use InvalidSerCommitSeqNo to mean "not
> committed yet", it made more sense to set it to UINT64_MAX so that
> if a comparison did sneak in it would do the right thing.
> 
> I did dust off a copy of the ANSI standard at the time, and it was
> pretty explicit that UINT64_MAX is supposed to be defined in
> <stdint.h>. But that may just be a C99 requirement (I didn't have
> an older copy of the standard), and it's obviously no guarantee
> that it actually is defined.
 
Attached is something which will work.  Whether people prefer this
or a definition of UINT64_MAX in some header file (if it's missing)
doesn't matter much to me.
 
At any rate, if someone commits this one-liner, three critters
should go back to green.
 
-Kevin