Re: Re: [COMMITTERS] pgsql: Adjust OLDSERXID_MAX_PAGE based on BLCKSZ.
От | Tom Lane |
---|---|
Тема | Re: Re: [COMMITTERS] pgsql: Adjust OLDSERXID_MAX_PAGE based on BLCKSZ. |
Дата | |
Msg-id | 26556.1310135343@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Re: [COMMITTERS] pgsql: Adjust OLDSERXID_MAX_PAGE based on BLCKSZ. (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Re: [COMMITTERS] pgsql: Adjust OLDSERXID_MAX_PAGE based
on BLCKSZ.
Re: Re: [COMMITTERS] pgsql: Adjust OLDSERXID_MAX_PAGE based on BLCKSZ. |
Список | 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 по дате отправления: