Re: pgsql error - Mailing list pgsql-general

From Tom Lane
Subject Re: pgsql error
Date
Msg-id 8919.1311689135@sss.pgh.pa.us
Whole thread Raw
In response to pgsql error  ("Mcleod, John" <johnm@spicergroup.com>)
List pgsql-general
"Mcleod, John" <johnm@spicergroup.com> writes:
> Thank you for the reply.
> At command line, I ran...
> "psql  --version"
> and received..
> "psql  (PostgreSQL) 7.5devel"

Egad.  That is an early development snapshot of what eventually got
called the 8.0 release.  You should try "select version();" in psql
to verify that the server itself is the same version, but I'm
betting it is.  What you've got there is a development snapshot from
perhaps mid-2004, and even if it were a supported release, we dropped
support for it a couple years ago.

> The database is sitting on a Windows 2003 Server box.

Even worse.  8.0 was the first release that had native Windows support
(so that probably explains why your predecessor tried to use it
pre-release).  The number and extent of the bugs in that is, well,
remarkable.

Given this information, what's remarkable is not that your DB got
corrupted but that it survived this long without that.  I think your
best bet is (1) pg_dump as much data as you can, (2) reinstall a
reasonably recent, supported PG version, (3) reload the dump.

> I know in the past, the project manager would restart the database by just closing the .bat window, then restart by
double-clickingthe postgis.bat file on the desktop. 
> I'm not sure if this was the beginning of the problem.

Sure didn't help any ... in principle the DB ought to withstand that,
but it's not a clean shutdown; and in the case of early Windows versions
in particular I'm not sure we understood how to do fsyncs correctly on
that platform.

I'm not a Windows person myself, but I believe the recent EDB packagings
of Postgres offer a much cleaner user interface than that.

            regards, tom lane

pgsql-general by date:

Previous
From: Allan Kamau
Date:
Subject: Re: 100 times faster than mysql
Next
From: Chris Travers
Date:
Subject: Re: Implementing "thick"/"fat" databases