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
|
Список | 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 по дате отправления: