Re: SSI patch version 14

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Dan Ports" <drkp(at)csail(dot)mit(dot)edu>, "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: <simon(at)2ndQuadrant(dot)com>,<markus(at)bluegap(dot)ch>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SSI patch version 14
Date: 2011-02-08 15:50:05
Message-ID: 4D5111CD020000250003A61B@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dan Ports <drkp(at)csail(dot)mit(dot)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

Attachment Content-Type Size
UINT64_MAX-elimination.patch text/plain 801 bytes

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-02-08 15:53:58 Re: Add ENCODING option to COPY
Previous Message Pavel Stehule 2011-02-08 15:42:56 Re: Re: patch: fix performance problems with repated decomprimation of varlena values in plpgsql