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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dave Page <dpage(at)postgresql(dot)org>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-committers <pgsql-committers(at)postgresql(dot)org>
Subject: Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64
Date: 2011-04-28 19:44:26
Message-ID: 2467.1304019866@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Dave Page <dpage(at)postgresql(dot)org> writes:
> On Thu, Apr 28, 2011 at 6:21 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Dave Page 2011-04-28 19:57:14 Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64
Previous Message Dave Page 2011-04-28 19:33:44 Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2011-04-28 19:57:14 Re: pgsql: Fix pg_size_pretty() to avoid overflow for inputs close to INT64
Previous Message Noah Misch 2011-04-28 19:41:12 ALTER TYPE DROP + composite-typed col vs. pg_upgrade