From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, rhaas(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Re: [COMMITTERS] pgsql: Adjust OLDSERXID_MAX_PAGE based on BLCKSZ. |
Date: | 2011-07-08 14:29:03 |
Message-ID: | 26556.1310135343@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> On 08.07.2011 15:22, Kevin Grittner wrote:
>> Heikki Linnakangas wrote:
>>> I'm getting a bunch of warnings on Windows related to this:
>>> .\src\backend\storage\lmgr\predicate.c(768): warning C4307: '+' :
>>> integral constant overflow
>> The part of the expression which is probably causing this:
>>
>> (MaxTransactionId + 1) / OLDSERXID_ENTRIESPERPAGE - 1
>>
>> Which I fear may not be getting into overflow which will not do the
>> right thing even where there is no warning. :-(
>>
>> Would it be safe to assume that integer division would do the right
>> thing if we drop both of the "off by one" adjustments and use?:
>>
>> MaxTransactionId / OLDSERXID_ENTRIESPERPAGE
> Hmm, that seems more correct to me anyway. We are trying to calculate
> which page xid MaxTransactionId would be stored on, if the SLRU didn't
> have a size limit. You calculate that with simply MaxTransactionId /
> OLDSERXID_ENTRIESPERPAGE.
So, what are the consequences if a compiler allows the expression to
overflow to zero? Does this mean that beta3 is dangerously broken?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2011-07-08 14:34:24 | Re: Re: [COMMITTERS] pgsql: Adjust OLDSERXID_MAX_PAGE based on BLCKSZ. |
Previous Message | Tom Lane | 2011-07-08 14:21:41 | Re: spinlock contention |