Re: Re: [COMMITTERS] pgsql: Adjust OLDSERXID_MAX_PAGE based on BLCKSZ. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Re: [COMMITTERS] pgsql: Adjust OLDSERXID_MAX_PAGE based on BLCKSZ.
Date
Msg-id 26556.1310135343@sss.pgh.pa.us
Whole thread Raw
In response to Re: Re: [COMMITTERS] pgsql: Adjust OLDSERXID_MAX_PAGE based on BLCKSZ.  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: Re: [COMMITTERS] pgsql: Adjust OLDSERXID_MAX_PAGE based on BLCKSZ.
Re: Re: [COMMITTERS] pgsql: Adjust OLDSERXID_MAX_PAGE based on BLCKSZ.
List pgsql-hackers
Heikki Linnakangas <heikki.linnakangas@enterprisedb.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: spinlock contention
Next
From: Heikki Linnakangas
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Adjust OLDSERXID_MAX_PAGE based on BLCKSZ.