Thread: integer datetimes
Our docs for the integer datetime option says: Use 64-bit integer storage for datetimes and intervals, rather than the default floating-point storage. This reduces the range of representable values but guarantees microsecond precision across the full range (see Section 8.5 for more information). Note also that the integer datetimes code is newer than the floating-point code, and we still find bugs in it from time to time. Is the last sentence about bugs really true anymore? At least the buildfarm seems to have a lot *more* machines with it enabled than without. (I'm thinking about making it the defautl for the vc++ build, which is why I came across that) //Magnus
Magnus Hagander <magnus@hagander.net> writes:
> Our docs for the integer datetime option says:
> Note also that the integer datetimes
> code is newer than the floating-point code, and we still find bugs in it
> from time to time.
> Is the last sentence about bugs really true anymore? At least the buildfarm
> seems to have a lot *more* machines with it enabled than without.
Buildfarm proves only that the regression tests don't expose any bugs,
not that there aren't any.
> (I'm thinking about making it the defautl for the vc++ build, which is
> why I came across that)
FWIW, there are several Linux distros that build their RPMs that way,
so it's not like people aren't using it. But it seems like we find bugs
in the datetime/interval stuff all the time, as people trip over
different weird edge cases.
regards, tom lane
On Wed, Feb 14, 2007 at 11:27:31AM -0500, Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: > > Our docs for the integer datetime option says: > > Note also that the integer datetimes > > code is newer than the floating-point code, and we still find bugs in it > > from time to time. > > > Is the last sentence about bugs really true anymore? At least the buildfarm > > seems to have a lot *more* machines with it enabled than without. > > Buildfarm proves only that the regression tests don't expose any bugs, > not that there aren't any. > > > (I'm thinking about making it the defautl for the vc++ build, which is > > why I came across that) > > FWIW, there are several Linux distros that build their RPMs that way, > so it's not like people aren't using it. But it seems like we find bugs > in the datetime/interval stuff all the time, as people trip over > different weird edge cases. Certainly, but is it more likely to trip on these in the integer datetime case, really? //Magnus
Tom Lane wrote: > Magnus Hagander <magnus@hagander.net> writes: > >> Our docs for the integer datetime option says: >> Note also that the integer datetimes >> code is newer than the floating-point code, and we still find bugs in it >> from time to time. >> > > >> Is the last sentence about bugs really true anymore? At least the buildfarm >> seems to have a lot *more* machines with it enabled than without. >> > > Buildfarm proves only that the regression tests don't expose any bugs, > not that there aren't any. > > >> (I'm thinking about making it the defautl for the vc++ build, which is >> why I came across that) >> > > FWIW, there are several Linux distros that build their RPMs that way, > so it's not like people aren't using it. But it seems like we find bugs > in the datetime/interval stuff all the time, as people trip over > different weird edge cases. > > > I think it's disappointing, to say the least, that we treat this code as a sort of second class citizen. BTW, the buildfarm has a majority of machines using it by design - it's in the default set of options in the distributed config file. If we think there are bugs we haven't found, then we need to engage in some sort of analytical effort to isolate them. I don't see any reason in principle why this code should be any more buggy than the float based datetimes, and I see plenty of reason in principle why we should make sure it's right. cheers andrew
On Wed, Feb 14, 2007 at 12:38:12PM -0500, Andrew Dunstan wrote: > Tom Lane wrote: > >Magnus Hagander <magnus@hagander.net> writes: > > > >>Our docs for the integer datetime option says: > >>Note also that the integer datetimes > >>code is newer than the floating-point code, and we still find bugs in it > >>from time to time. > >> > > > > > >>Is the last sentence about bugs really true anymore? At least the > >>buildfarm > >>seems to have a lot *more* machines with it enabled than without. > >> > > > >Buildfarm proves only that the regression tests don't expose any bugs, > >not that there aren't any. > > > > > >>(I'm thinking about making it the defautl for the vc++ build, which is > >>why I came across that) > >> > > > >FWIW, there are several Linux distros that build their RPMs that way, > >so it's not like people aren't using it. But it seems like we find bugs > >in the datetime/interval stuff all the time, as people trip over > >different weird edge cases. > > > > > > > > I think it's disappointing, to say the least, that we treat this code as > a sort of second class citizen. BTW, the buildfarm has a majority of > machines using it by design - it's in the default set of options in the > distributed config file. If we think there are bugs we haven't found, > then we need to engage in some sort of analytical effort to isolate > them. I don't see any reason in principle why this code should be any > more buggy than the float based datetimes, and I see plenty of reason in > principle why we should make sure it's right. That was exactly what I thought, which is why I was kinda surprised to see that note in the configure stuff. If we go with that, then we can say that *any* new feature is less tested, no? ;-) //Magnus
OK, mention removed. We can always re-add it if we find we need to warn people away from integer timestamps again. --------------------------------------------------------------------------- Magnus Hagander wrote: > On Wed, Feb 14, 2007 at 12:38:12PM -0500, Andrew Dunstan wrote: > > Tom Lane wrote: > > >Magnus Hagander <magnus@hagander.net> writes: > > > > > >>Our docs for the integer datetime option says: > > >>Note also that the integer datetimes > > >>code is newer than the floating-point code, and we still find bugs in it > > >>from time to time. > > >> > > > > > > > > >>Is the last sentence about bugs really true anymore? At least the > > >>buildfarm > > >>seems to have a lot *more* machines with it enabled than without. > > >> > > > > > >Buildfarm proves only that the regression tests don't expose any bugs, > > >not that there aren't any. > > > > > > > > >>(I'm thinking about making it the defautl for the vc++ build, which is > > >>why I came across that) > > >> > > > > > >FWIW, there are several Linux distros that build their RPMs that way, > > >so it's not like people aren't using it. But it seems like we find bugs > > >in the datetime/interval stuff all the time, as people trip over > > >different weird edge cases. > > > > > > > > > > > > > I think it's disappointing, to say the least, that we treat this code as > > a sort of second class citizen. BTW, the buildfarm has a majority of > > machines using it by design - it's in the default set of options in the > > distributed config file. If we think there are bugs we haven't found, > > then we need to engage in some sort of analytical effort to isolate > > them. I don't see any reason in principle why this code should be any > > more buggy than the float based datetimes, and I see plenty of reason in > > principle why we should make sure it's right. > > That was exactly what I thought, which is why I was kinda surprised to > see that note in the configure stuff. > > If we go with that, then we can say that *any* new feature is less > tested, no? ;-) > > //Magnus > > ---------------------------(end of broadcast)--------------------------- > TIP 7: You can help support the PostgreSQL project by donating at > > http://www.postgresql.org/about/donate -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: doc/src/sgml/installation.sgml =================================================================== RCS file: /cvsroot/pgsql/doc/src/sgml/installation.sgml,v retrieving revision 1.282 diff -c -c -r1.282 installation.sgml *** doc/src/sgml/installation.sgml 3 Feb 2007 23:01:06 -0000 1.282 --- doc/src/sgml/installation.sgml 17 Feb 2007 01:24:57 -0000 *************** *** 965,973 **** the full range (see <![%standalone-include[the documentation about datetime datatypes]]> <![%standalone-ignore[<xref linkend="datatype-datetime">]]> ! for more information). Note also that the integer datetimes code is ! newer than the floating-point code, and we still find bugs in it from ! time to time. </para> </listitem> </varlistentry> --- 965,971 ---- the full range (see <![%standalone-include[the documentation about datetime datatypes]]> <![%standalone-ignore[<xref linkend="datatype-datetime">]]> ! for more information). </para> </listitem> </varlistentry>