"Kevin Grittner" <kevin.gritt...@wicourts.gov> writes:
> Tom Lane <t...@sss.pgh.pa.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 ...
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
