More useful info: (and yes I'm replying to my own message)
I spelunked through the source code and found this in times.cc:
LONGLONG
hires_ms::usecs (bool justdelta)
{
if (!minperiod) /* NO_COPY variable */
prime ();
DWORD now = timeGetTime ();
// FIXME: Not sure how this will handle the 49.71 day wrap around
LONGLONG res = initime_us.QuadPart + ((LONGLONG) (now - initime_ms) *
1000);
return res;
}
That method call is the guts of the gettimeofday() function which is
called by the postgres now() stored procedure. Note the FIXME comment.
This wraparound is where now() is going kaboom.
I haven't fully grokked what's going on here yet, I just stumbled upon
it. I believe that Win32 makes it hard to get a current time with
usecs, so cygwin must be doing some interval calculating, which
obviously will wrap eventually.
I'd love to get this fixed. I'd love to fix it myself if no one is
currently working on it, but I'd also love some suggestions or more info
on cygwin's operation in this area. Any suggestions are welcome. (plead
plead plead)
Thanks!
McC
[EMAIL PROTECTED]
On Sun, 2004-06-27 at 10:37, Sean McCune wrote:
> Folks,
>
> I've run into a problem affecting postgres on cygwin 1.5.7 (yes, we're
> upgrading, but those things have to be scheduled and infrequent). We
> have several systems that, after running for a month or two, will
> exhibit the following symptom: "select now()" will start returning the
> time at which the database started up (or thereabouts) rather than the
> current time. In one case now() was latched at that time forever. In
> another case now() seemed to drop back to that time but kept running
> from there.
>
> I am in the process now putting together an upgrade that will include
> the latest version of cygwin. Once I have it tested, I will deploy it
> and in a month or two I'll know if the latest version suffers the same
> problem or not. But that's not a very good way of solving it, and it
> won't make the users of the system happy. :)
>
> I found the following two messages in the cygwin archives that detailed
> problems in the same area, but not exactly the same symptoms.
>
> http://sources.redhat.com/ml/cygwin/2004-01/msg01392.html
>
> http://www.cygwin.com/ml/cygwin/2003-07/msg01016.html
>
>
> I was unable to duplicate either my symptoms or the symptoms described
> above by changing the Windows system time as described in the above
> messages. In fact, I can't cause my problem to occur at will. It only
> occurs after letting the system run live and be used in production
> (heavy use) for a month or two.
>
> The postgres folk feel its definitely a cygwin problem because postgres
> does not keep its own time. It only reports what ftime/gettimeofday
> tells it. They have anecdotal remembrances of cygwin users describing
> this problem to them before.
>
> Has anyone here had and successfully dealt with this problem? I'd like
> to believe the cause attributed to in the messages above is it, so it
> could be fixed. But since the symptoms aren't exactly the same and I
> can't duplicate using their method, I doubt it.
>
> Thanks in advance for any info or advice. :)
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
