Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64
Дата
Msg-id 2467.1304019866@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64  (Dave Page <dpage@postgresql.org>)
Ответы Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64  (Dave Page <dpage@postgresql.org>)
Список pgsql-committers
Dave Page <dpage@postgresql.org> writes:
> On Thu, Apr 28, 2011 at 6:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Dave, can you poke at this?

> I think we may have to award Sun (or whats left of them) the "Bizarre
> compiler bug of the week" award here.

Yeah.  Has anyone filed a report with them?

> It's actually the val++; that's
> causing the assertion, but I'm darned if I can get it to work. I've
> tried spelling out the addition, casting, changing val to an int64*,
> renaming val, and probably a dozen or so things that are broken, all
> with no success.
> Any other ideas?

I was suspicious that it had something to do with the compiler trying to
optimize the size / mult and size % mult subexpressions to get both
results with one division instruction.  Can you check if removing either
of those makes the crash go away?

If it does have something to do with that, my inclination is to fix it
by rewriting the function to depend on shifting rather than division.
I was considering doing that anyway but decided it was pointless
micro-optimization.  However, if it dodges a compiler bug ...

            regards, tom lane

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

Предыдущее
От: Dave Page
Дата:
Сообщение: Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64
Следующее
От: Dave Page
Дата:
Сообщение: Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64