On Thu, 2004-02-26 at 11:46, Holger Marzen wrote:
On Thu, 26 Feb 2004, Jeffrey W. Baker wrote:
We are using PostgreSQL with the database and xlogs on (separate) XFS volumes under Linux 2.4.25. We are simply curious to hear your experiences with this combination, if you are using it. In only two days of heavy activity, we've already been able to corrupt one database. We've also seen XFS panic because of inconsistent in-memory metadata. Frankly we don't have the highest confidence.
I am afraid that xfs in that kernel or your hardware is buggy (probably RAM). A 24h run of memtest86 wouldn't be bad.
Since PostgreSQL uses the operating system's calls for file operations as any other program does, it's most probably no PostgreSQL issue.
I don't see why not.
Because Postgres is in use on systems all over the place without problems.
PostgreSQL could easily have a bug that swaps a buffer somewhere, resulting in a corrupt table.
Not easily. If such a bug existed, I would think that someone else would have complained about it before now. I have 3 Postgres servers under varying levels of usage - all are rock solid reliable, with uptimes easily over 30 days without problems. These crashes you describe are unlikely to be coming from Postgres.
That we see this only on the INSERT path and not the COMMIT path also seems to point towards Pg.
Not really.
Have you used something like bonnie++ to test XFS for reliability? Have you run memtest86 as was suggested?
In my experience, faulty hardware is far more common than what you are suggesting.
Anyway, you didn't mention XFS. Do you have experience using it beneath Postgres?
Personally, I have tested it for its performance capabilities, but never deployed it long-term. However, in my experience, it works reliably.
-- Bill Moran Potential Technologies http://www.potentialtech.com
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
