Re: Re: Backups WAS: 2 gig file size limit
От | Joseph Shraibman |
---|---|
Тема | Re: Re: Backups WAS: 2 gig file size limit |
Дата | |
Msg-id | 3B4B5A1C.FA6F8418@selectacast.net обсуждение исходный текст |
Ответ на | Re: [HACKERS] 2 gig file size limit (Lamar Owen <lamar.owen@wgcr.org>) |
Список | pgsql-general |
I mentioned this on general a while ago. I had the problem when I dumped my 7.0.3 db to upgrade to 7.1. I had to modify the dump because there were some 60 seconds in there. It was obvious in the code in backend/utils/adt/datetime that it was using sprintf to do the formatting, and sprintf was taking the the float the represented the seconds and rounding it. select '2001-07-10 15:39:59.999'::timestamp; ?column? --------------------------- 2001-07-10 15:39:60.00-04 (1 row) Thomas Lockhart wrote: > > > > Have you observed otherwise? > > Yes. Specifically timestamps are dumped in a way that (1) they lose > > percision (2) sometimes have 60 in the seconds field which prevents the > > dump from being restored. > > The loss of precision for timestamp data stems from conservative > attempts to get consistant behavior from the data type. It is certainly > not entirely successful, but changes would have to solve some of these > problems without introducing more. > > I've only seen the "60 seconds problem" with earlier Mandrake distros > which combined normal compiler optimizations with a "fast math" > optimization, against the apparent advice of the gcc developers. What > kind of system are you on, and how did you build PostgreSQL? > > Regards. > > - Thomas -- Joseph Shraibman jks@selectacast.net Increase signal to noise ratio. http://www.targabot.com
В списке pgsql-general по дате отправления: