>You don't need to do any data migration to get off 7.2.3 -- 7.2.4 is
>a drop-in replacement, so you should at least do that upgrade first.
Thanks for the information. If I can simply do a drop-in replacement,
that may be something I can try. But I am still thinking there could
be other cases database will get corrupted due to power failure and
will not be able to startup correctly again. (missing some pg_files)
>But I don't think that power failures would be enough to cause the
>kind of problem you're describing, unless you're running without
>fsync or something. Care to give more details?
>In any case, I think that your script is mighty dangerous. It sounds
>like a recipe for data loss to me. Postgres is considerably more
>robust than this, and I think you're trying to cover up some serious
>problems that you may have, likely with your hardware.
And you have pointed out my concern. Even though we have WAL
enable, we have intentionally disabled both fsync and fdatasync
inside the kernel because of other reasons. As long as there are
ways I can eliminate database being corrupted (or correctly and
automatically detected the corruption and drop the tables if
necessary), that should satisfy my need.
The persistence of the data is important for me, but disk performance
and availability of a funcational database has a higher priority for my
need.
Thanks,
--muteki
_________________________________________________________________
Let the advanced features & services of MSN Internet Software maximize your
online time. http://click.atdmt.com/AVE/go/onm00200363ave/direct/01/