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

On Fri, Jul 8, 2011 at 11:57 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> At this point I think the actual choice we'd have is to abandon
>>> beta3 and try again next week with a beta4.  I'm trying to figure
>>> out whether this bug is serious enough to warrant that, but it's
>>> not clear to me.
>
>> I changed the definition to this:
>
>> #define OLDSERXID_MAX_PAGE (-1)
>
>> That caused my compiler to report the following warnings:
>
>> predicate.c: In function *OldSerXidAdd*:
>> predicate.c:828: warning: division by zero
>> predicate.c:848: warning: division by zero
>> predicate.c: In function *OldSerXidGetMinConflictCommitSeqNo*:
>> predicate.c:958: warning: division by zero
>> predicate.c: In function *CheckPointPredicate*:
>> predicate.c:1038: warning: division by zero
>
>> It's hard to imagine that any compiler would evaluate it to -1
>> instead of the value it's had all along (including beta2) and not
>> generate these warnings, too.
>
> The value of OLDSERXID_ENTRIESPERPAGE includes a sizeof() call, so
> every compiler I've ever heard of is going to consider it an unsigned
> value, so we should be getting an unsigned comparison in the Min().
> So I think you are right that OLDSERXID_MAX_PAGE should end up with
> its old value.  Still, it's a bit nervous-making to have such problems
> popping up with a patch that went in at the eleventh hour --- and it
> was about the least of the last-minute patches for SSI, too.  So
> color me uncomfortable ...

I agree.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company