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 27965.1310139531@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Re: [COMMITTERS] pgsql: Adjust OLDSERXID_MAX_PAGE based on BLCKSZ.  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Re: [COMMITTERS] pgsql: Adjust OLDSERXID_MAX_PAGE based on BLCKSZ.
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Jul 8, 2011 at 10:57 AM, Heikki Linnakangas
> <heikki.linnakangas@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.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: API for GetConfigOption()
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: News on Clang