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 (AT) redhandsoftware (DOT) com


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Sean McCune <sean (AT) redhandsoftware (DOT) com> writes:
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

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

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:

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Sean McCune wrote:
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

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)

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
Red Hand Software, Inc.
sean (AT) redhandsoftware (DOT) com
Land: 724-224-7323
Cell: 724-316-5456
Fax: 412-291-1520




---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo (AT) postgresql (DOT) org

On Fri, Jun 25, 2004 at 06:35:08PM -0400, Sean McCune wrote:
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)


---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings