Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Fri, Jul 8, 2011 at 10:57 AM, Heikki Linnakangas >> <heikki.linnakan...@enterprisedb.com> wrote: >>> So if MaxTransactionId+1 overflows to zero, OLDSERXID_MAX_PAGE >>> becomes -1. Or a very high value, if the result of that is >>> unsigned, as at least MSVC seems to interpret it given the other >>> warning I got. If it's interpreted as a large unsigned value, >>> then the SLRU_PAGES_PER_SEGMENT * 0x10000 - 1 value wins. That's >>> what what we had prior to this patch, in beta2, so we're back to >>> square one. If it's interpreted as signed -1, then bad things >>> will happen as soon as the SLRU is used. > >> Should we, then, consider rewrapping beta3? > > 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. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
