From: | Andrew Sullivan <ajs(at)crankycanuck(dot)ca> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: pg_class and relfilenode |
Date: | 2004-02-13 12:26:49 |
Message-ID: | 20040213122649.GC2222@phlogiston.dyndns.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Wed, Feb 11, 2004 at 10:08:30PM -0800, muteki muteki wrote:
> 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)
Under nromal operation, there is _no way_ you should get a corrupted
database from a power failure. PostgreSQL's WAL system is designed
to handle machine crashes, but only. . .
> enable, we have intentionally disabled both fsync and fdatasync
> inside the kernel because of other reasons.
. . .if you don't do things like that. That is, frankly, just a
recipe for disaster. Your attempts to work around this are likely to
cause at least as much damage as the corruption you might get from
power failures. I advise you very strongly to reconsider your
approach.
> 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.
I think you are very likely to make your database all but completely
useless with this strategy. What will you do if you get, say, a
corrupted pg_class table? Can't drop that -- you'll have no database
that you can see.
A
--
Andrew Sullivan
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Sullivan | 2004-02-13 12:35:35 | Re: Idle Connection force-close ? |
Previous Message | Andrew Sullivan | 2004-02-13 12:17:16 | Re: Quad Xeon vs. Dual Itanium |