Re: [BUG] Denormal float values break backup/restore
От | Tom Lane |
---|---|
Тема | Re: [BUG] Denormal float values break backup/restore |
Дата | |
Msg-id | 23398.1307732241@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [BUG] Denormal float values break backup/restore (Marti Raudsepp <marti@juffo.org>) |
Ответы |
Re: [BUG] Denormal float values break backup/restore
|
Список | pgsql-hackers |
Marti Raudsepp <marti@juffo.org> writes: > On Fri, Jun 10, 2011 at 17:20, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> I put this right about on par with the occasional suggestions that we >> implement our own filesystem. > I am worried that legitimate calculations can bring the database into > a state where a backup succeeds, but is no longer restorable. > Obviously making reliable backups is the job of a database. Yes, but my point is that Postgres cannot be held accountable for every misfeature of the platforms we are using. We are not replacing libc any more than we are replacing the filesystem, or the TCP stack, or several other components that people have trouble with from time to time. We don't have the manpower, nor the expertise, to take responsibility for all that stuff. > I see four ways to make this work: > 1. Clamp denormal numbers to 0.0 when stored into a table. > 2. Throw an error when denormal numbers are stored into a table. > 3. Use the FTZ (flush-to-zero) FPU mode so denormal values never > appear. I'm not sure whether this is available on all target > architectures. > 4. Change the float4in and float8in functions to accept denormal float > literals. This has a nice side-effect of enabling full IEEE 754 > floating point range. Or (5) Lobby your libc providers to make strtod accept denormals without throwing ERANGE. There is no obvious reason why it shouldn't. (On at least one of my boxes, it does.) regards, tom lane
В списке pgsql-hackers по дате отправления: