Hello QuingQing,
>
> What is your file system, NTFS or FAT32? Is that table newly created?
File System is NTFS. That table was created with database installation,
which was short after after release of PostgreSQL 8.0 - so that database was
in use for > 9 months. That table is a central table of the application, and
is used very often ... the application was running for the whole 9 months :)
So there is a valid record in pg_class but the representing data file is
> lost ... a possible theory of what's happened could be:
>
> 1) create the table;
> 2) a checkpoint happens;
> 3) lost power;
> [ restar the machine and database ]
> 4) file system recovery - unable to recovery your data file;
> 5) database recovery - don't play WAL and recreate your data file because
> of the checkpoint;
Is that possible?
>
Rather not ... that table was there from the beginning and for some months.
(it gets created with initial database install)
The only strange thing is that short 3 lines log before the big error. As to
power loss: that is a laptop; so "loosing power" would need to take out the
accumulator. Which is quite possible, but rather unlikely given the
technical level of the user.
postgresql-2005-11-21_080758.log
2005-11-21 08:08:05 LOG: startup process (PID 1220) exited with unexpected
status 128
2005-11-21 08:08:05 LOG: aborting startup due to startup process failure
2005-11-21 08:08:06 LOG: logger shutting down
postgresql-2005-11-21_084022.log
2005-11-21 08:40:24 LOG: database system was shut down at 2005-11-20
16:46:29 Westeurop=E4ische Normalzeit
--> can that exiting process with 128 be a sign of "system gets killed while
postgres is starting up"? (and taking a file with it????)
As much as I learned, PostgreSQL only APPENDS to the data files; and only a
vacuum full can truncate them ... and on that machine there is no vacuum
full happening.
It still keeps being a mystery.
Harald
--
GHUM Harald Massa
persuasion python postgresql
Harald Armin Massa
Reinsburgstra=DFe 202b
70197 Stuttgart
0173/9409607