[EMAIL PROTECTED] writes: > I am running PostgreSQL 7.2.1 distributed with cygwin on > Windows NT4 SP6.
7.2.1 has known bugs; why are you not testing 7.2.3? > The data directory is on NTFS drive. Not sure that we can do much about an inherently unreliable platform :-(. I do not know whether cygwin (or even bare NT) provides any write-ordering guarantees --- anyone able to say anything authoritative about the behavior of fsync on this platform? In any case, there is *no one* who will claim that cygwin/NT offers the sort of production-grade stability that you are evidently looking for. Forget that OS and get yourself a recent Linux release. But having said all that, I suspect that your real issue is not a software problem at all, but hardware: > 2002-12-09 15:43:16 [180] FATAL 2: open of /cygdrive/d/TEMP/data/pg_clog/0677 >failed: No such file or directory We've seen several similar reports of attempted clog access far past the actual end of clog (ie, an attempt to determine the commit status of a garbage transaction number) and in every case where it was possible to trace the cause, the cause was corrupted data pages on-disk. A totally trashed disk page will often show this failure before any other evidence appears of the data corruption, just because checking the transaction numbers in tuple headers is one of the first steps in trying to use data. So I rather suspect that the real issue is your disk drive doesn't behave well when it loses power while writing. I can't prove it at a distance, but that's what I'd be looking into if I were you. If you want to try to learn more from the evidence you have, I'd suggest trying to identify the trashed data pages to see if there's any pattern to them. A useful low-level tool for this is pg_filedump from http://sources.redhat.com/rhdb/tools.html. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
