| 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: | Whole Thread | Raw Message | 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 |