Обсуждение: Problem with now() on 7.4.1-3 under cygwin?
Hi all, We're running 7.4.1-3 under cygwin on Windows 2003 Server. We're going to upgrade to the latest, but it takes some time to schedule this on the various systems its running on. The system gets heavy usage... 43000 tiff files of about 30-40kb each have been inserted over a 3 month period. What we've found is that every month or two now() starts returning the date and time when the database was started. In two cases now() latched at that time and reported it forever. In the third case it reset to that time and started ticking forward from there. We cannot cause this problem to happen at will, and it has only occurred on production systems that get heavy usage. We've never seen it happen on our development or QA systems, but they don't get as heavy usage over as long a period of time as the production systems, obviously. When it occurs we see a timestamp field associated with a tiff image that holds the date/time of image insertion drop back to this earlier database startup time. At that point, I can log into psql and start doing "select now()" queries and watch it either return that database startup time over and over again or watch it start keeping time again from that database startup time. I have not run into this problem under Linux before, but that doesn't mean anything. This application running under cygwin is more heavy duty than what I've run on Linux. So we don't know if its a general postgres bug or something that's only occurring on cygwin. I tried to search for this issue in the archives of pgsql-bugs on the website, but the search engine seems to be down. So be gentle with the RTFMs. :) The upshot is, I don't know if this is an existing issue, solved issue, or something new... or if somehow we have broken it. :) I have not been able to find a bugzilla or RT URL to search through postgres bugs. Is this not publicly available? Are the pgsql-bugs archives the only way to search for existing and/or solved bugs? Thanks in advance , Sean McCune sean@redhandsoftware.com
Sean McCune <sean@redhandsoftware.com> writes:
> I have not run into this problem under Linux before, but that doesn't
> mean anything. This application running under cygwin is more heavy duty
> than what I've run on Linux. So we don't know if its a general postgres
> bug or something that's only occurring on cygwin.
We have heard of similar things under cygwin, so I'd suppose it's a
cygwin bug. Postgres does not do its own timekeeping --- it believes
whatever time(2) and gettimeofday(2) tell it --- so it's definitely an
OS-level problem.
regards, tom lane
OK, I'll look at it from the cygwin end. Its interesting that restarting postgres clears it. Although, I guess this could be a problem in the cygwin DLL. Thanks for the very quick response! McC Tom Lane wrote: >Sean McCune <sean@redhandsoftware.com> writes: > > >>I have not run into this problem under Linux before, but that doesn't >>mean anything. This application running under cygwin is more heavy duty >>than what I've run on Linux. So we don't know if its a general postgres >>bug or something that's only occurring on cygwin. >> >> > >We have heard of similar things under cygwin, so I'd suppose it's a >cygwin bug. Postgres does not do its own timekeeping --- it believes >whatever time(2) and gettimeofday(2) tell it --- so it's definitely an >OS-level problem. > > regards, tom lane > >
Sean McCune wrote: > OK, I'll look at it from the cygwin end. Its interesting that > restarting postgres clears it. Although, I guess this could be a > problem in the cygwin DLL. Thanks for the very quick response! Just for the record, I had a client report the same thing a couple of days ago with (iirc) the dbexperts version. Restarting PG fixed it there too. -- Richard Huxton Archonet Ltd
I'm not familiar with dbexperts version, but I think that's a native Win32 version, which shoots down cygwin as the culprit and starts pointing the finger at Windows. That figures. On Fri, 2004-06-25 at 06:39, Richard Huxton wrote: > Sean McCune wrote: > > OK, I'll look at it from the cygwin end. Its interesting that > > restarting postgres clears it. Although, I guess this could be a > > problem in the cygwin DLL. Thanks for the very quick response! > > Just for the record, I had a client report the same thing a couple of > days ago with (iirc) the dbexperts version. Restarting PG fixed it there > too. -- Sean McCune Red Hand Software, Inc. sean@redhandsoftware.com Land: 724-224-7323 Cell: 724-316-5456 Fax: 412-291-1520
On Fri, Jun 25, 2004 at 06:35:08PM -0400, Sean McCune wrote: > I'm not familiar with dbexperts version, but I think that's a native > Win32 version, which shoots down cygwin as the culprit and starts > pointing the finger at Windows. That figures. Actually, AFAIR it _is_ a Cygwin version, relabeled and with the DLLs renamed so it's not obvious that Cygwin is there. Or something like that. -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "In a specialized industrial society, it would be a disaster to have kids running around loose." (Paul Graham)