Re: Re: [COMMITTERS] pgsql: Adjust OLDSERXID_MAX_PAGE based on BLCKSZ.

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

In response to

Responses

Browse pgsql-hackers by date

  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